AI Coding 实践（AI Coding）

“我不会写代码，也能做应用吗？”

在 AI Coding 的语境下，答案是：可以从“会描述”开始。你不一定要懂所有语法，但要学会把需求说清楚。

自然语言编程：Chat-to-Code 的基本方式

Chat-to-Code 的重点不是“让 AI 代写”，而是“让你更快迭代”。

你可以这样开始：

1. 先描述目标（功能、范围、限制）。
2. 要最小可用版本（MVP）。
3. 再逐步加功能。

例如：

请用 JavaScript 写一个 3 秒倒计时的示例，输出到控制台，不要使用外部库。

可能得到这样的代码：

let count = 3;
const timer = setInterval(() => {
  console.log(count);
  count -= 1;
  if (count === 0) {
    clearInterval(timer);
    console.log("start");
  }
}, 1000);

然后你可以继续迭代：

很好，现在改成从页面上的按钮触发倒计时，倒计时数字显示在按钮上。

每一步都小而可控。先跑通，再优化。

提醒：AI 生成的代码也可能有 bug，务必运行并验证。不要因为是 AI 写的就默认它是对的。

环境配置：让协作更顺滑

想把 AI Coding 用得顺手，环境配置会直接影响体验。

常见组合：

• VS Code + Copilot：适合已有开发环境的人，代码补全体验好。
• Cursor / Windsurf：AI 原生编辑器，对话和代码修改更紧密。
• Claude Code / Gemini CLI：命令行 Agent，适合喜欢终端的开发者。

你不需要一下子切换所有工具。先从“让 AI 进编辑器”开始，就已经是质变。选一个顺手的，用熟了再说。

项目实战：从 0 到 1 的小应用

练习的目标不是做大项目，而是跑通流程。比如做一个“每日任务清单”：

1. 定义需求：添加/完成/删除任务。
2. 拆分模块：数据结构、UI、事件处理。
3. 先做最小版本：能新增和显示即可。
4. 逐步增强：加入持久化和样式。

AI 可以帮你写代码，但需求拆解仍然要你来做。你负责方向，AI 负责实现。

架构优先：先想清楚结构，再写代码

在开始写代码之前，花 5 分钟想清楚架构，能省下后面几小时的返工。

什么是架构？简单说就是：

• 数据怎么存：用什么数据结构？存在哪里？
• 模块怎么分：哪些功能放在一起？哪些要分开？
• 接口怎么定：模块之间怎么通信？

你可以先让 AI 帮你画架构。

我要做一个记账 App。请先给出技术方案：用什么框架、怎么组织文件结构、数据怎么存储。不要写代码，先讨论方案。

等方案讨论清楚了，再开始写代码。这比直接让 AI “帮我写一个记账 App” 效果好得多。

Plan Mode：先规划，再动手

一些 AI 编程工具（比如 Claude Code）提供了 Plan Mode：一个专门用来“想”的阶段，和“做”的阶段分开。

在 Plan Mode 下，AI 只做三件事：

1. 探索：读代码、搜文件、理解现有结构。
2. 设计：分析需求，提出实现方案，列出关键文件和步骤。
3. 确认：把方案呈现给你，等你批准后再动手写代码。

Plan Mode 的价值在于：你能在 AI 动手之前就知道它打算怎么做。如果方案有问题，这个阶段改方案的成本最低：改一行方案描述，比改十行已经写好的代码便宜得多。

# 进入 Plan Mode
> 我想给这个项目加一个用户登录功能。先不写代码，帮我分析一下需要改哪些文件、用什么方案。

# AI 分析完，你确认方案后
# 退出 Plan Mode，进入实现阶段
> 好，按刚才的方案开始实现。

这和“架构优先”是同一个思路：先想清楚，再动手。Plan Mode 只是把这个思路工具化了。

自主编码循环：持续实现、验证和修正

在 AI 编程里，更通用的说法是自主编码循环（autonomous coding loop）或编码 Agent 的执行-反馈循环（agentic coding loop）。它指的是：让 AI 围绕同一个目标持续工作，写代码、运行验证、根据错误修正，再进入下一轮，直到达到明确的验收标准。

有些社区会把其中一种做法叫 Ralph Loop 或 Wiggum loop。这个名字来自《辛普森一家》里的 Ralph Wiggum：一个总是犯迷糊、总是出错、但从不放弃的小男孩。这个说法可以当作案例理解，但它不是初学者必须掌握的基础术语。先记住“计划、执行、验证、修正”这条循环，更有助于继续学习。

传统的 AI 编程流程是：

你：帮我实现这个功能。
AI：写了一段代码。
你：有 bug。
AI：修了这个 bug。
你：还有别的问题。
AI：（上下文不够了，或者放弃了）

自主编码循环的流程是：

你：帮我实现这个功能。遇到错误就修，直到所有测试通过、所有需求满足。
AI：写了一段代码 → 跑测试 → 发现 2 个失败 → 修复 → 再跑 → 还有 1 个失败 → 修复 → 全部通过。

区别在于：你不需要在每一步都手动介入。你给 AI 一个明确的目标和验收标准，它自己循环执行，直到达标。

怎么用好自主编码循环：

• 给明确的验收标准：“所有测试通过”“能正常运行”“没有 TypeScript 类型错误”。标准越明确，AI 越不容易“偷懒”。
• 给最大循环次数：防止 AI 在同一个问题上死循环。“最多尝试 10 次，如果还不行就停下来告诉我卡在哪里。”
• 每一步都要验证：AI 不能只“说”它修好了，必须跑测试、跑代码来证明。

自主编码循环适合的场景：修 bug、补测试、代码迁移、格式化等有明确“完成标准”的任务。不太适合需要设计判断的任务（比如“帮我设计一个好看的 UI”）。

提醒：自主编码循环的“不放弃”不等于“不思考”。如果 AI 在同一个问题上连续失败 3 次以上，通常是它理解错了需求，而不是“再试一次就好了”。这时候应该停下来，重新描述问题。

局限与注意事项

AI Coding 很强大，但它有明确的边界。了解这些边界，才能用好它。

架构债务

AI 倾向于“能跑就行”。它不会主动考虑代码的可维护性、可扩展性、可测试性。

如果你一直让 AI “加功能”而不重构，项目会越来越臃肿，最终变成一个难以维护的“技术债务”。

应对：定期让 AI 帮你重构。每隔一段时间，停下来问一句：“这段代码有什么可以优化的？”

上下文爆炸

当项目变大，AI 会失去全局视角。它可能不知道你 3 天前写的那个函数是干什么的，也不知道你昨天改的那个配置会影响什么。

这是目前所有 AI 编辑器的共同局限。

应对：保持代码结构清晰，用注释和文档记录关键决策。不要完全依赖 AI 的“记忆力”。

确认偏误在编码中的体现

还记得上一章提到的确认偏误吗？在 AI Coding 中，它表现为：

• 你说“这个函数对吗？”AI 大概率说“看起来没问题”。
• 你说“帮我加这个功能”，AI 不会主动说“这个需求本身有问题”。

应对：主动要求 AI 审查你的代码和需求。“这段代码有什么潜在问题？”“这个需求有没有更好的实现方式？”

安全盲区

AI 不会主动考虑安全问题。它可能生成：

• 没有输入验证的表单。
• 硬编码的密钥和密码。
• 没有权限检查的 API。

应对：在 Prompt 中明确安全要求。“请加上输入验证”“不要硬编码任何敏感信息”“需要做权限检查”。

小结

• AI Coding 的重点是会表达：把需求说清楚，AI 帮你实现。
• 最小可用加迭代是常用节奏，先跑通再优化。
• 架构优先：先想清楚结构，再写代码。
• Plan Mode 把“规划”和“实现”分开，让你在 AI 动手之前就能审核方案。
• 自主编码循环让 AI 持续工作直到达标，适合有明确验收标准的任务。
• 了解边界：架构债务、上下文爆炸、确认偏误、安全盲区，都是真实存在的问题。
• 应用尽用：能用 AI Coding 解决的问题就用，但要知道它不适合什么。

练习

1. 写一个“最小可用版本”的需求描述（不超过 80 字），让 AI 生成代码并运行。
2. 在让 AI 写代码之前，先让它给出技术方案（框架选择、文件结构、数据存储）。对比“先方案后代码”和“直接写代码”的区别。
3. 找一段 AI 生成的代码，主动要求 AI 审查它：“这段代码有什么潜在问题？有没有安全隐患？”

延伸阅读

• 调试 Debug
• 测试 Testing
• 安全与安全性 Safety & Security