工程稳定 · 维护 · 交付

工程设计从已经确认的业务对象、字段、状态、角色、规则和异常情况开始，再分别写进数据模型、状态机、权限矩阵、校验规则和接口约定。

关键规则要查得到来源和版本。规则变了，就要同时检查数据迁移、历史记录、接口兼容和测试范围，不能只改页面上的一句话。

业务架构说明有哪些角色、工作和流程；应用架构说明各模块负责什么；数据架构说明对象、口径、流向和保存方式；技术架构说明运行环境、依赖、接口和部署方式。

四个方面要互相对得上。业务对象在数据中找不到位置、模块职责和运行边界不清，或所选技术超过团队的维护能力，问题迟早会在交付时暴露。

工程文档至少要说明需求和范围、架构和关键决定、数据和接口、测试和验收、部署和运行。篇幅可以短，但接手的人必须找得到当前事实和重要限制。

代码变更时，相关文档也要更新。版本、负责人和适用范围应当写进正文，否则旧文档会把接手的人带到错误方向。

同一个人可以兼任产品、架构、开发、测试和运行，但每次检查都要说明当前承担哪项责任。这样才看得出“功能已经做完”和“功能已经验证”之间还有没有空档。

一人兼任多项工作，不能代替正式分工。涉及专业审批、安全、隐私和生产发布，仍要由有相应权限并承担责任的人确认。

交付前，要按风险安排单元、集成、端到端、权限、数据、构建和安全检查。关键流程没有通过、验收条件不全或无法回滚，候选版本就不能交付。

测试结果必须注明版本和环境。内部功能检查、正式用户验收测试（UAT）、预生产验证和生产验收是不同阶段，不能互相替代。

交付前要核对配置、数据迁移、依赖、账号、监控、备份、恢复和回滚方案；交付时写明当前版本、已知限制、操作方法和负责人。

运行中的告警、故障、反馈和变更要留在可追查的记录中。问题处理完，再判断需要补测试、改规则、调架构，还是更新操作说明。

AI 可以帮助加快开发，但不能跳过工程设计和交付检查。开始以前，要写清任务范围、允许修改的目录、验收标准和敏感信息限制。

生成的代码仍要经过代码审查、自动测试和实际运行检查。来源、实际作用或安全影响无法确认的改动不能进入交付版本，最终责任由项目成员承担。

项目结束后，留下经过验证的模板、检查表、组件、测试脚本、架构决定和运行说明，并注明适用条件。尚未验证的设想要和这些材料分开保存。

再次使用前，要检查环境和限制是否改变。条件变了，就回到原理和证据重新判断，不能把旧项目的做法当成通用答案。