边界意识比较成熟
主动区分营销域与供应链、生产、财务等权威系统，能够降低重复建设和口径冲突。
01 — 整体印象现有设计已体现
现有设计已体现
较强专业基础
团队已经超越“用 AI 提高编码速度”的阶段，开始系统处理需求上下文、业务边界、权限、变更、验收与独立验证等真正困难的问题。当前可以肯定的是设计意识与方法方向较强；下一轮要验证的是这些机制是否已经稳定进入真实项目。
整体方向是对的。后续工作的重点不是再增加一套规范，而是把“设计得很好”验证成“实际也能稳定跑通”。
不是单点功能堆砌
身份、门户、流程、集成和多角色渠道被放在同一架构中统筹考虑。
具备企业级接入意识
员工委托授权、业务服务继续鉴权、工具白名单、审计与人工确认原则值得保留。
抓住 AI 开发的核心风险
SDD、EARS、规格分级、负空间和 Delta 变更，有助于减少意图漂移与范围蔓延。
重视独立验证与分层测试
实现者与验证者分离，并覆盖多层测试，已经具备“反假完成”的方法意识。
为未来保留了选择权
模型、知识库、MCP 工具和外部能力避免强绑定单一供应商，有利于持续演进。
02 — 评审框架四条线需要
四条线需要
相互印证
项目不只需要一次技术架构 review。业务是否成立、用户是否好用、软件是否可靠、AI 研发是否真实运转，必须放到同一条业务链路上观察。
1
业务与功能
核心经营问题是什么？规则、数据、责任人和结果是否被功能完整承接？
2
产品与交互
真实用户怎样完成任务？正常、异常、回退、跨角色和移动场景是否顺畅？
3
技术与质量
架构是否解耦、可扩展、可测试？数据、权限、接口和故障边界是否清楚？
4
AI 原生研发
AI 如何获得上下文、完成变更、被独立验证，并把反馈送回下一轮？
03 — 业务与产品从功能清单走向
从功能清单走向
经营闭环
平台覆盖范围已经比较完整。下一步最有价值的动作，是选出第一阶段最重要的三条跨角色业务链路，用同一套事实检验需求、交互、架构和测试。
一条业务链路应从“触发”一直回到“效果”
只有执行结果能回到下一轮策略，平台才真正形成经营闭环；每条闭环都应同时覆盖正常、异常、权限和跨角色协作。
建议团队先回答的业务问题
最先解决什么断点
一期最重要的三条业务闭环是什么？原流程在哪个节点损失效率、数据或经营判断？
谁确认、谁负责
哪些规则已经由业务负责人确认？指标和关键数据分别由谁维护、谁解释？
真实用户怎样完成任务
跨角色、移动端、弱网、异常、撤回和重试时，用户路径是否仍然完整？
04 — 技术架构方向合理，下一步验证
方向合理，下一步验证
边界是否真正可执行
现有蓝图已经覆盖多角色接入、营销能力、共享服务、数据与外部系统，并把 AI 与治理作为横切能力。后续 review 的重点，是图上的分层能否在代码、数据和运行故障中保持一致。
核心业务保持稳定，外部系统和 AI 能力通过清晰边界接入
最值得优先保护的是营销核心业务规则；主数据、指标、权限和接口契约决定整个平台能否长期保持一致。
建议优先验证的六个架构属性
数据权威源唯一
每类核心数据只有一个权威来源，服务职责与负责人能够被明确说明。
外部能力可替换
SAP、物流、消息、模型和第三方数据通过适配层接入，不侵入核心规则。
模块可独立验证
外部接口未到位时，仍可通过契约、模拟器和隔离数据验证核心链路。
失败能够恢复
重试、幂等、补偿、对账、回滚与人工处理入口保持业务状态一致。
拆分由真实需要触发
新增服务或平台能力由团队边界、容量、独立发布和真实场景需要触发。
可替换、可追溯
模型与 Prompt 有版本，输入依据、人工修改、输出与最终动作都能留痕。
05 — 测试与质量测试不是“数字好看”
测试不是“数字好看”
而是业务能够被证明
现有规范已经覆盖 EARS 追溯、分层测试、契约测试、Playwright、CI 门禁和独立 Verifier，这套书面体系明显高于一般内部项目。下一步需要验证它是否真正运行。
覆盖率用于发现盲区；关键质量结论来自“核心业务规则—对应测试—运行结果”的可追溯关系。
| 测试层级 | 主要证明什么 | 千禾场景应特别关注 | 希望看到的证据 |
|---|---|---|---|
| 单元 / 组件 | 规则和局部交互是否正确 | 费用、政策、状态机、计算口径、表单边界 | 关键断言、分支覆盖、失败用例 |
| 接口 / 契约 | 服务边界和数据格式是否稳定 | SAP、订单、库存、物流、主数据同步 | 契约测试、模拟器、错误与超时响应 |
| 集成 / 数据 | 跨模块状态与数据是否一致 | 幂等、重试、补偿、对账、权限和并发 | 测试环境、数据样本、异常恢复结果 |
| 端到端 E2E | 真实用户是否能完成任务 | 连续 UI 输入、跨角色、移动端、异常与回退 | Playwright 源码、结果、截图或短录屏 |
| 部署后验证 | 真实入口和运行环境是否可用 | 认证、网关、依赖、配置、监控与回滚 | 探针、发布记录、告警和回滚演练 |
建议的 coverage 口径同时报告行覆盖、分支覆盖和统计范围；再把核心业务规则逐条映射到对应测试。高覆盖率不能替代正确的业务断言，E2E 数量也不能替代真实用户旅程。
06 — AI 开发工作流用一个真实功能
用一个真实功能
证明工作流
现有 SDD、EARS、角色分工与验证机制方向很好。最有效的下一步，不是继续增加流程说明，而是选一项真实功能，完整回放下面这条证据链。
证据链完整，AI 工作流才真正形成闭环
一次真实回放比再写一份流程说明更有价值：它能同时暴露上下文、门禁、测试、部署与反馈中的断点。
已经抓住的关键机制
- 规格分级与 Delta 变更
- 实现者与验证者分离
- 需求、验收、代码与测试可追溯
- 生产密钥和高风险动作保留人工边界
下一轮重点确认
- 哪些门禁自动执行，哪些需要人工判断
- Verifier 是否拥有独立上下文与结构化证据
- 部署后的反馈如何进入缺陷与需求队列
- 模型、Prompt、评测与失败回退如何管理
07 — 下一步材料只需要一个
只需要一个
轻量证据包
不要求团队为了本次交流重新制作完整文档。请选择一个最有代表性的真实功能，直接提供当前已有版本；缺少的内容标注“暂无”即可。
用一个样本看穿整套方法，比收集十份泛化说明更快、更准确。
- 需求与验收——当前版 PRD、用户故事或需求说明，以及 EARS 或其他可执行验收标准。
- 场景测试——正常、异常、权限与端到端场景；最好标明哪些是真实连续 UI 操作，哪些使用 API、seed 或 mock。
- 自动化结果——最近一次 CI 回执、各层实际测试数、失败与跳过、覆盖率统计范围及 E2E 结果。
- 一次 AI 任务——输入上下文、主要代码变更或 PR、独立验证记录；如方便，可提供代码仓只读权限或代表性模块脱敏快照。
- 运行证明——10—15 分钟带版本号的短录屏，展示真实输入、跨角色流转、一次异常修正和最终结果；无需专门安排完整 Live Demo。
- 项目全局补充——第一阶段最重要的三条营销业务闭环，以及当前架构中哪些已实现、建设中或仍在规划。
收到后可以快速完成什么
| 可以直接异步审阅 | 必须取得代码或运行证据后才能判断 |
|---|---|
| PRD 是否覆盖角色、规则、异常和可验收结果 | 模块是否真实解耦、扩展点与依赖是否合理 |
| EARS 与测试是否逐条映射，关键业务终态是否有断言 | AI 生成代码的可维护性、安全、错误处理与性能 |
| 真业务旅程与页面冒烟、单点交互是否被混淆 | 权限隔离、并发幂等、非法状态流转和失败补偿 |
| CI 门禁是否覆盖目标模块，skip / retry 是否掩盖失败 | E2E 是否可重复、是否真实落库以及部署回滚能力 |
建议的协作方式材料齐备后先异步 review，再集中讨论少数真正影响项目成败的问题。这样既节省团队准备和会议时间，也能让讨论建立在可复核的事实之上。
评审边界本页基于现有需求规划、企业架构蓝图与 AI 开发规范形成，只评价设计意识与方法方向，不把文档中的规划视为已经完成的实现。