为什么需要工程模式
让 AI 写代码很容易，让 AI 可靠地写代码不容易——一次没想清楚的大改，足以把项目拖进返工泥潭。普通的 AI 编程工具「你问它答、边说边改」，快，但把可靠性押在了模型的自觉上。
工程模式把「设计先行、评审把关、验证收尾」从口头叮嘱升级为半机械流程：能被机器拦住的环节一律拦住，拦不住的才交给纪律约束。核心承诺只有一句——代码必须先有被评审过的设计。这不是提醒，是闸门。
四步流程，一步不跳
需求 → 设计 → 开发 → 测试。每个请求都走完整流程，不因「看起来很简单」而抄近道；需要抄近道时，由轻通道显式放行（见下），而不是悄悄省略。需求落成验收条目、设计落成设计文档、实施落成批次记录——每一步都有据可查。
两道门禁
- 设计评审（第一道）：独立评审子代理以全新视角审查设计文档——挑问题、给依据，逐条裁决修正后签发实施令牌。评审对象由任务定义，不靠遍历猜测。
- 代码评审（第二道）：实现完成后自动触发独立代码评审（逐轮收敛、引用逐字机械校验；同因反复失败会停下并明确上报）——发现问题在实现者内部闭环修正，收敛才交付。
硬拦截：没评审过，写不进去
写文件门禁 + 令牌校验：没有通过设计评审的实现，一个字节都写不进你的仓库。这是机械约束，不依赖模型的心情，也不给你「它这次应该会守规矩吧」的侥幸空间。
分工与隔离
- 设计者（eng-designer）：只写设计与文档，不碰代码。
- 实现者（eng-coder）：只按设计实现——改动范围与验收标准先钉死在任务书里，再动手。
- 评审者：只读、独立上下文——「自己评自己」的盲区不存在。
全程留痕，可追溯
每次实施都有批次记录（讨论、设计、评审、批准、实施、验证六段）与任务台账——谁在什么时候、因为什么证据、做了什么决定，全部可追溯、可复盘。中断了接着干，换人了也对得上账。
轻通道：小事不摆大阵仗
改文案、调参数、修小缺陷、走查当场点名的问题——走轻通道：直接改，收尾时统一补一次完整评审与记录。流程服务于可靠性，不是负担——该重的地方重，该轻的地方轻，边界写死。
开启方式
- CLI：输入
/eng。 - 桌面版：点输入区的 ENG 钮。
- 任意端：在配置中设置
"agent.engineering": true（新会话初值——三端共用配置；会话内可随时开关，以会话态为准，见 配置参考）。