跳到正文

免费公开课程 · 8/40

第 8 章 三大纪律与一条补充原则

本章目标

必交产物:三大纪律检查单

  1. O1 · 能够解释“目标约束”“验收纪律”“恢复边界”之间的依赖层次(产物:三大纪律检查单)

    证据:三大纪律检查单按依赖关系排列“目标约束”“验收纪律”和“恢复边界”

  2. O2 · 能够自下而上构造三大纪律检查单并为每层写出完成证据(产物:三大纪律检查单)

    证据:三大纪律检查单为每一层写出输入、完成标准和可复核证据

  3. O3 · 能够用目标、验收和恢复三项纪律诊断一个失控任务(产物:三大纪律检查单)

    证据:产物指出一个失控任务最先缺失的纪律及修复顺序

前置学习:第 7 章 六步工作法:AI 辅助编程的核心流程

初学者路径

本章迁移任务是:能够用目标、验收和恢复三项纪律诊断一个失控任务。先按图中的“前置依赖”关系完成三大纪律检查单的第一项证据,再逐项核对责任人与判断标准。

有经验者路径

先用当前项目完成这一任务:能够用目标、验收和恢复三项纪律诊断一个失控任务。提交三大纪律检查单后,再对照正文复核关系类型、缺失证据和授权边界。

第 8 章三大纪律检查单教学图
从底层前置条件读到上层结果,用三大纪律检查单定位不能被高层表现掩盖的缺口。
图解文字说明

图将三大纪律检查单画成三级阶梯,底层“目标约束”支撑中层“验收纪律”,中层再支撑上层“恢复边界”。层级表达前置依赖而非重要性排名;任一底层证据缺失时,上层结果不能视为已成立。

关系语义:三层自下而上形成前置依赖;上层不能补偿下层缺口,诊断必须回到最早失效层。

**公开课程改编版。**正文依据内部教材整理,保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学,不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限;重试次数不自动触发恢复;恢复须先保护工作并确认目标、共享状态和外部数据影响。

课程讲解

在六步工作法之上,还有三条贯穿始终的纪律。违反任何一条,都可能导致项目失控。

8.1 无蓝图不开工

不要在没有架构设计的情况下直接让 AI 写代码。

为什么?新会话能使用的信息取决于系统实际提供的上下文;未提供的项目约束不能假定模型知道。如果不给它蓝图,它会依据当前输入补全技术栈、命名风格和数据结构,不同输入可能产生不一致结果。你今天让 AI 做用户管理,它采用一种命名风格;明天让 AI 做订单管理,它采用另一种——两个模块的数据模型就可能冲突。

这几分钟的设计,能帮你省下后面数小时级别的返工(量级示例,具体数字因项目而异)。

8.2 无验收不固化

不要在没有验收的情况下提交 AI 生成的代码。

为什么?因为 AI 存在”自洽陷阱”——它生成的代码看起来”对”,但可能逻辑错误、边界缺失、安全漏洞。功能测试只会检查”注册成功”,不会检查”密码是否加密”。如果提交了未验收的代码,这些隐藏的问题就被固化成了代码库的一部分。

让 AI 自查可以补充检查视角,但同一模型的复核不是独立证据。至少还要运行可执行检查,并由有权限的人核对架构、安全和业务边界。

8.3 逢混乱必重建

如果你发现 AI 的代码偏离蓝图太远,或者在修修补补中变得越来越乱,果断回滚重来。

为什么?因为修复成本可能高于重建成本。具体的算力与人力经济账、量级示例及其适用边界,以第 7.5 节含工作保护与验证成本的计算为准。

回滚不可耻,在错误的基础上修修补补才可耻。

8.4 补充原则:无术语不讨论

在讨论技术方案之前,先对齐核心领域术语。

这不是纪律——违反后不会导致项目失控——但能显著提升沟通效率。术语模糊意味着架构从一开始就是模糊的:同一个“订单”在销售、财务和仓库语境中可能分别指向购买请求、已支付交易和待发货工作单,从而导向不同的数据模型、状态机和 API 设计。第 12 章说明如何把这种分歧写入术语表。

8.5 每条纪律背后的推演链(理解”为什么”比记住”是什么”更重要)

三大纪律看似简单,但每一条背后都有一个完整的推演链。理解这些推演链,比记住三大纪律本身更重要。

纪律一:没有蓝图不开工。

  • 推演链:项目约束未进入当前上下文 → 模型只能依据已给信息补全空白 → 不同上下文可能得到不同约定 → 多个功能的数据模型、命名风格冲突 → 返工和风险增加。
  • 关键洞察:蓝图不是文档,是”约束器”。它把 AI 的可能性空间从”无限”压缩到”你的项目范围内”。当蓝图说”使用 Prisma ORM、camelCase 命名、统一 AppException 异常处理”时,AI 无论开多少次对话都会遵守这些约定,因为它每次看到蓝图时,这些”规则”都是固定的。
  • 推论:蓝图应覆盖当前任务所需的关键约束、保持准确且便于检索;不必追求囊括整个系统,但未覆盖项要明确标成未知并触发确认。

纪律二:没有验收不固化。

  • 推演链:流畅代码可能仍有语法、逻辑、架构或安全缺陷 → 单一顺利路径测试只能证明有限行为 → 未检查的风险进入代码库 → 后续修改继续依赖它。
  • 关键洞察:一个典型场景——你让 AI 实现用户注册,测试跑通,注册成功登录成功,你提交了代码。但一个月后你发现密码是明文存储的——因为功能测试只检查了”注册成功”这个结果,没有检查”密码是否加密”这个实现细节。“自洽陷阱”的意思是:AI 会让自己看起来”正确”,即使底层逻辑是错的。它不会主动告诉你”我用了明文存储密码”,因为它认为”跑通了”就是”完成了”。
  • 推论:验收不能只看”能不能跑通”,还要看是否满足已声明的功能、架构和安全标准。三类检查互补,但都不能保证发现所有隐藏问题(详见第 9 章)。

纪律三:逢混乱必重建。

  • 推演链:生成可能便宜,但保护工作、理解和验证仍有成本 → 在混乱代码上比较修补与重建总成本 → 若有可验证的恢复点且重建更合适,按第 10.4 节恢复后用更精确的指令重新生成。
  • 关键洞察:经济账的完整教学计算见第 7.5 节;它支持的不是“任何问题都重建”,而是在混乱代码上先比较修复与重建的总成本。
  • 推论:重建信号与最终分支判断以第 9 章的验收决策树为准。

独立练习

使用虚构或已获授权的脱敏材料,先独立作答,再查看参考。将产物保存为 chapter-08.md,写上版本、决定、证据和缺项。

拟定蓝图缺失、检查失败、上下文矛盾三种情况下的行动卡,写是否继续、保存什么、谁确认。

本章必交产物:三大纪律检查单

以下证据必须出现在本次独立练习的提交物中;正文原有问题用于提供内容,不能替代这些验收项。

  • O1: 三大纪律检查单按依赖关系排列“目标约束”“验收纪律”和“恢复边界”
  • O2: 三大纪律检查单为每一层写出输入、完成标准和可复核证据
  • O3: 产物指出一个失控任务最先缺失的纪律及修复顺序
查看参考反馈(先独立作答)

参考反馈

没有蓝图时先补范围与契约;检查失败时记录缺项再修复;上下文矛盾时保存工作并核验文档。重复失败是重新诊断的信号,不是自动清空项目的授权。恢复前确认目标、共享状态与外部数据影响。

自评与下一步

对照本章目标检查:决定是否明确,依据是否能复现,未知项是否如实记录。参考给出一种判断方式,不是唯一答案;若不同结论能提供同等证据,可请同伴复核。缺少证据的部分记未完成,再回到对应步骤补充。

来源与边界

登记来源只支持本章涉及的外部事实;三大纪律检查单、示例数字和练习情境属于课程内部教学设计,必须在实际项目中重新验证。

  • Git 官方参考

    Git project · 2026-09-17 · 版本、分支、提交与恢复操作须按实际仓库状态验证。

  • NIST AI 风险管理框架

    National Institute of Standards and Technology · 2026-09-17 · AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。

记录本章练习

仅保存本浏览器的自检记录,不上传作业,不代表评阅通过或认证。请在自己的章节文件中保留证据与缺项。

进阶培训即将上线,当前暂不提供 →