实战报告：AI Coding 具备交付能力，但高度依赖结构化约束

事件概述

本次实践旨在验证 AI Coding 能否从“局部辅助写代码”进阶为“参与完整交付流程”。作者未使用现有业务项目，而是搭建脱敏演示环境，通过三个递进场景（从 0 到 1 初始化、已有项目迭代、老项目补规范）进行测试。最终结论是：AI Coding 已具备交付能力，但必须建立在约束清楚、边界明确、验收方式可执行的基础上。

核心信息

1. 适用场景与局限性

• 适合场景：
  • 新项目初始化及最小功能闭环构建。
  • 结构相对清楚的已有项目进行小至中等规模迭代（前提是边界已框定）。
  • 约束缺失但仍可运行的老项目（需先补最小规范再开发）。
• 不适合场景：
  • 高不确定性、强业务耦合且依赖隐性经验的任务。
  • 直接对老项目进行无规范的功能开发。
• 定位：AI 更像是一个需要被精确定义、约束和验证的协作对象，而非能自动收口的全能开发者。

2. 关键变量：输入质量决定结果

• 问题根源：偏差往往发生在“理解任务”阶段，而非代码生成阶段。模糊的需求描述会导致 AI 基于默认假设进行猜测，从而引入不可控风险。
• 解决方案：将需求文档从“给人看的描述”转变为“给机器执行的说明”。
  • 显式化内容：必须明确写出目标、不做事项、规则边界、验收标准、回退方案及 Feature Flag 控制逻辑。
  • 示例对比：仅描述“做一个表单”会导致字段设计、校验程度、测试要求等全由 AI 猜测；而结构化定义（如指定字段类型、枚举值、Lint/Build 命令）则能显著提升稳定性。

3. 场景一验证：从 0 到 1 的项目初始化

• 目标：在无上下文情况下，构建一个具备持续迭代能力的现代化前端项目基线。
• 执行策略：
  • 事前规划：先让 AI 输出实施计划（步骤拆解、文件变更、依赖检查），确认方向无误后再编码。
  • 技术栈约束：明确指定 pnpm, Vite, React, TypeScript, Biome, Vitest, Husky 等工具链。
  • 工程规范：强制要求目录结构清晰、脚本统一（lint/test/build/dev）、README 完备。
• 结果：AI 成功搭建了符合规范的基线，并完成了首个“新增用户表单”功能的最小闭环（含校验、Feature Flag、单测及 Playwright 自动化验收）。证明只要规格清晰，AI 能同时处理代码实现与工程约束。

4. 场景二验证：已有项目的迭代开发

• 挑战：在已有项目中加需求，难点在于控制改动范围，避免破坏原有结构或引入不协调的代码风格。
• 执行策略：
  • 边界先行：在编码前强制要求 AI 输出“文件改动清单”、“实现计划”及“风险边界说明”，严禁顺手优化无关结构。
  • 职责分离：确保页面层仅负责渲染切换，数据与逻辑下沉至 lib 层。
• 结果：在新增“用户列表页”功能时，AI 严格限制了改动范围（仅修改 App.tsx 状态切换，新增 UserListPage 及过滤逻辑），未引入多余依赖或过度设计。测试覆盖关键行为（渲染、搜索过滤、空态展示），并通过独立测试验证了底层逻辑的正确性。

值得关注

• 交付标准的转变：真正的交付不仅是代码跑通，还包括完整的自动化验收（如 Playwright 端到端测试）和清晰的变更说明。
• 自然语言即代码：当需求定义足够结构化时，自然语言描述本身即可作为执行指令，其确定性甚至优于部分传统代码注释。
• 风险控制：在复杂项目中，防止 AI“顺手优化”导致的架构漂移比单纯的功能实现更为重要，必须通过前置的边界定义来锁定改动范围。