系统边界梳理
画清服务、数据、角色、外部依赖和关键状态流转，识别真正的耦合点。
先确认业务与数据条件
真正昂贵的不是代码量，而是错误方向持续累积
当系统边界、数据责任和技术决策缺少共同事实，团队会把大量时间花在重复讨论、跨系统补洞和无法复盘的上线风险上。
老系统继续叠加功能，但没有人能说清跨服务影响和改造顺序
数据口径、状态流转和权限分散，任何新功能都会牵动多个团队
项目已经进行一半，范围、架构或供应商方案仍然无法验收
准备开发新平台，却没有清楚的边界、迁移计划和上线责任
团队想接入 AI，但不知道应该先补数据、后台还是 Agent 层
缺少长期技术负责人，需要资深判断而不是增加一个开发人手
从真实系统开始
把争论转成可以核对的架构事实与优先级
Review 不替业务负责人做决定，而是把现状、约束、风险和选择写成共同证据，让下一阶段能被拆分、验收和接手。
风险分级
按 P0 / P1 / P2 区分阻断项、上线前必须解决项和后续优化项。
数据与 AI 接入判断
判断 AI 应该接在哪里，以及何时应先补后台、数据治理或权限模型。
重构与迁移路线
拆出可独立验证的阶段，避免一次性重写和无法回滚的大版本。
交付与验收机制
明确责任人、书面规格、验收样本、变更记录和上线放行条件。
持续技术顾问
在 Review 之后按明确范围持续评审关键决策、风险和交付证据。
低风险入口
固定范围 Review：CTO / 架构入口
不预设最终方案，也不把 Review 变成长期驻场。先用有限时间找到最重要的系统风险和决策，再由你决定内部执行、外部建设或持续顾问。
- 时间
- 通常 2 周
- 商务方式
- 固定范围 / 固定价
固定交付物
- 现状、目标与约束边界
- 关键系统与数据流架构图
- P0 / P1 / P2 发现清单
- 方案选择与不选某条路的理由
- 分阶段整改 / 建设路线图
- 一次最终 Review 会议
范围确认后提供固定报价。审查结束后，再决定是否进入建设或持续顾问合作。
提交系统背景先把边界讲清楚
关于 CTO / 技术架构 Review 的常见问题
这里集中回答交付对象、适用场景、上线控制和合作起点。展开问题即可查看完整边界。
不需要。Review 先判断业务目标、系统边界和主要风险，也可能得出先补后台、数据或团队机制，暂时不做 Agent 的结论。
重点不是尽快拆功能报价，而是把关键架构判断、责任边界、风险优先级和可以验收的下一阶段写清，让团队能据此继续、暂停或调整方向。
固定范围内交付现状与目标边界、关键架构图、P0 / P1 / P2 发现、优先决策、分阶段路线图和一次最终 Review 会议。
不必须。交付物可供内部团队或其他供应商执行；如果需要资深判断持续跟进，再进入建设或 Fractional CTO / 技术顾问合作。