很多人把 AI 编码的不稳定归因于模型本身，但在真实项目里，更常见的原因是任务说明不完整。页面结构没写清楚、功能边界没写清楚、UI 约束没写清楚、验收标准没写清楚，最后模型当然只能在模糊空间里猜。
一份好的工程说明书，不是为了“写得漂亮”，而是为了让 Codex 能稳定理解目标、限制修改范围、遵守既有结构，并且在完成后可以被验证。这篇教程就是把这种说明方式拆成可复用的框架。
如果只给出一个零散改动请求，模型会倾向于把局部问题当作全部问题处理。更稳妥的方式是先交代项目背景、当前页面的角色、用户场景和本次修改目标，让执行围绕真实业务而不是围绕局部样式变化展开。
对于页面或功能开发类任务，建议明确列出有哪些页面、每个页面承担什么职责、主要状态有哪些、关键交互有哪些、哪些区域可以复用组件。这样 Codex 不会把“补一个模块”误解成“重写整页”。
很多返工都不是因为做少了，而是因为做多了。工程说明书里应该明确哪些内容这次不改、哪些路由不能动、哪些依赖不要新增、哪些接口不要随意替换。边界写得越明确，执行越稳。
如果视觉要求只有“高级一点”“更好看”，模型很难稳定产出接近预期的结果。更有效的方式是写明色彩方向、信息层级、首屏重点、按钮优先级、图片比例、移动端适配要求，以及哪些设计模式必须保留。
真实项目里，透明 PNG、Logo 版本、2x/3x 尺寸、图标命名、裁切比例、背景图风格，都会影响页面成色。如果素材边界不写清楚，最后很容易出现“代码没错但视觉失真”的问题。
验收标准至少应包含：能否正常打开、核心流程是否闭环、移动端是否正常、构建是否报错、控制台是否有明显错误、是否还残留测试文案。只有把“完成”定义清楚，才谈得上减少返工。
工程说明书里可以记录后续可能做的方向，但不应混成当前轮次的硬要求。把“当前必做”和“未来可扩展”分开，能显著降低任务漂移和不必要的超范围修改。