让 AI 动手之前，先写一份可执行的任务书

让 AI 直接“做一个网站”是最容易返工的开场。不是 AI 不够强，而是任务本身没有边界：它不知道哪些不能改、哪些不能编、做到什么程度算完成。于是它会用最顺手的默认值补全一切，包括你根本没要的功能和根本不存在的数据。一份可执行的任务书，就是在动手之前把这些默认值堵住。

任务书至少要写清六件事

第一，目标与定位。用一句话说清这是什么、不是什么。例如个人技术品牌与内容平台，就不是单一工具站，也不是通用 SaaS 营销页。定位不清，导航和首页结构一定会跑偏。

第二，范围与不做清单。范围写“包含什么”，不做清单写“明确不做什么”。后者更重要：不做实际工具、不做登录支付评论、不做深色模式、不改 DNS 与生产配置。这些如果只留在口头里，执行时很容易被“顺手”做掉。

第三，事实基准。写清仓库、分支、当前提交、部署链路和已知问题。如果计划书与代码冲突，以哪一份为准也要写明。执行者不应该从代码反推并宣称外部配置一定正确。

第四，结构与数据来源。导航有几项、路由是什么、内容从哪里来、草稿怎么处理，都应该在动手前定下来。内容与工具尤其要分开：工具列表如果将来以数据注册表为唯一来源，初版就不应该先手工写一堆卡片。

第五，验收标准。构建命令是什么，哪些页面必须可访问，哪些页面必须 noindex，哪些视口必须检查，缺了哪一项就不算完成。验收标准写得越具体，返工越少。

第六，部署边界。能不能合并主分支、能不能触发生产部署、能不能改托管配置，必须明确。默认应该是“只在功能分支里做，不合并、不发布”，除非用户另外授权。

执行时坚持三条规则

第一条，先读再改。动手前读计划书、读现有配置、读相关文件，不要凭记忆改。结构性改动先说明方案，等确认再执行。

第二条，不虚构。没有数据就不写数据，没有工具就不列工具，没有来源就不编来源。空状态要诚实，草稿不能进生产列表和 sitemap。

第三条，改完自验。构建通过只是第一步，还要检查生成的页面：导航选中状态对不对，工具页有没有 noindex，sitemap 有没有多余页面，移动端会不会横向溢出。没有自验的“完成了”，只是把验证推给了用户。

一个可复用的检查句式

每次把任务交给 AI 之前，可以先问自己：目标是不是一句话能说清？不做清单有没有写？事实基准有没有给？验收标准能不能逐项打勾？部署边界有没有锁死？五项都齐了，再让它动手，返工率会明显下降。