文章目录
- 从问答式编程到任务式编程
- 真正拉开差距的是上下文工程
- 把 AI 当成项目成员，而不是代码补全
- 为什么很多人用起来效果一般
- 一本适合作为入门地图的书
- 我更建议这样读
- 最后
过去聊 AI 编程，很多人的第一反应还是“让它帮我写一段代码”。
这当然有用。写一个工具函数、补一个正则、解释一段报错，AI 的确能省下不少时间。但如果只停留在这个层面，它更像一个聪明的搜索框，或者一个随叫随到的代码片段生成器。真正有意思的变化，是它开始进入完整的开发流程：读项目、理解约束、拆任务、改多文件、跑命令、修失败、写测试、整理提交说明。
也就是说，AI 编程的重点正在从“生成代码”转向“组织工作”。
从问答式编程到任务式编程
早期使用 AI 写代码，我最常见的姿势是这样：
这里有个需求，帮我写一段 JavaScript。
或者：
这段 SQL 报错了，帮我看看哪里不对。
这种方式很自然，也很容易上手。但问题也明显：AI 拿到的是一个孤立片段，它不知道你的项目结构，不知道你们的命名习惯，不知道哪些工具链已经存在，也不知道这段代码最后要怎样被测试。
所以你会发现，它给出的答案有时“看起来对”，放进项目里却不一定能跑。
现在更值得尝试的方式，是把 AI 当成一个可以进入工程现场的协作者：
请先阅读这个仓库的目录结构，找出用户登录流程相关的模块。 然后说明现有实现，再帮我补一个“记住登录状态”的功能。 完成后运行测试，如果测试失败，继续修复。这类提示词没有直接要求它“写代码”，而是把任务放回项目语境里。它需要先理解，再动手，再验证。对开发者来说，这个转变很关键：你不再只是收代码，而是在设计一个可执行的开发流程。
真正拉开差距的是上下文工程
很多人觉得 AI 编程效果不稳定，本质上不是模型完全不行，而是上下文给得太散。
人类同事接手一个需求时，也需要知道几件事：
- 这个项目的技术栈是什么
- 哪些目录可以改，哪些目录不要碰
- 测试怎么跑
- 代码风格有什么约定
- 线上曾经踩过哪些坑
- 需求的边界在哪里
AI 也一样。
Claude Code 官方文档里提到，Claude Code 可以读取代码库、编辑文件、运行命令，并与开发工具集成；它也支持通过CLAUDE.md这类项目说明文件保存长期指令，让每次会话从同一套项目约定出发。这个点看似朴素，但实际非常有用。
一个简单的CLAUDE.md可能长这样：
# 项目约定 - 使用 pnpm，不要改成 npm 或 yarn。 - 新增业务逻辑时优先补单元测试。 - UI 组件放在 src/components，不要直接写进页面文件。 - 提交前运行 pnpm lint 和 pnpm test。 - 遇到不确定的产品逻辑，先列出假设，不要直接实现。这不是“提示词玄学”，更像是给 AI 一份项目入职文档。文档越清楚，它越不容易在重复问题上犯错。
把 AI 当成项目成员，而不是代码补全
我现在更倾向于把 AI 编程拆成四个阶段：
- 侦察：让它先读代码、找入口、画出调用链。
- 计划：让它说明准备改哪些文件、为什么这样改。
- 执行：让它按计划实现，并保持改动范围可控。
- 验证：让它跑测试、看日志、解释失败原因，再迭代。
这套流程并不复杂，但能明显减少“生成一大坨看似正确的代码”的风险。
尤其是在已有项目里，最怕的不是 AI 不会写代码，而是它太会写了：一旦上下文不够，它可能会绕开现有工具、重复造轮子，甚至把一个局部需求扩成一次不必要的大重构。
所以，好的 AI 编程不是让模型自由发挥，而是让它在约束里工作。
为什么很多人用起来效果一般
我观察到几个常见误区。
第一，把 AI 当外包。只丢一句“帮我做一个 XX 系统”，然后期待它一次性产出完整结果。现实是，工程任务很少能靠一句话解决。你越不参与设计，越容易得到一个能演示但难维护的东西。
第二，只看生成速度，不看验证闭环。AI 写得快，但快不等于对。让它跑测试、补测试、解释测试失败，往往比让它多写几百行代码更重要。
第三，不沉淀项目规则。每次都从零解释技术栈、目录、风格，既浪费上下文，也容易让结果漂移。把高频约定写进项目说明，比临场补充更稳定。
第四，忽略“可回退性”。AI 改代码时，最好让每次任务足够小，提交足够清晰。这样即使方向错了，也能快速撤回，而不是在一堆混合改动里找问题。
一本适合作为入门地图的书
最近我翻到一本新书：《Claude Code橙皮书：AI编程实战》。它由人民邮电出版社出版、图灵出品，作者是花叔，主题正好卡在“AI 编程从工具尝鲜走向工作流建设”这个节点上。
我比较喜欢它的一点是：它不是只讲“怎么安装一个工具”，而是把 Claude Code 的使用路径串成了一个递进路线：
- 工具认知与环境搭建
- 第一个项目如何落地
- 核心工作流怎么组织
CLAUDE.md如何配置- 对话策略怎么设计
- skill、Hook、MCP 怎么扩展能力
- 多智能体协作适合处理什么任务
- 通过 Chrome 扩展、内容创作自动化、应用程序开发等案例走完整流程
这类书的价值，不在于替代官方文档。官方文档适合查能力边界和参数，书更适合帮你建立一条学习路径。尤其是刚开始接触 AI 编程的人，很容易陷入“今天看一个提示词技巧，明天试一个插件”的碎片化状态。一本结构化的实战书，至少能帮你把这些散点接起来。
如果你已经会写代码，它可以帮你重新审视自己的开发流程：哪些步骤可以交给 AI 先跑一遍，哪些决策必须由人把关，哪些项目规则应该显式写下来。
如果你代码基础没那么强，它的意义也不只是“降低编程门槛”。更重要的是让你理解：用 AI 做产品，不等于完全不需要工程思维。需求拆解、验证、边界控制、版本管理，这些仍然是基本功。
我更建议这样读
如果你准备读这本书，我不建议从第一页开始像读小说一样顺着看完。更好的方式是边读边做。
可以按三个小目标推进：
- 先跑通一个最小项目：哪怕只是一个浏览器插件、脚本工具或内部小页面。
- 为项目写一份
CLAUDE.md：把技术栈、命令、风格、禁区写清楚。 - 让 AI 完成一次真实迭代：包括读代码、改代码、运行验证、整理变更。
读书的时候，不妨准备一个专门的实验仓库。每读到一个能力，就在仓库里做一个小实验。比如读到 Hook，就试着让格式化命令自动跑；读到 MCP，就想想哪些外部资料可以接入；读到多智能体协作，就尝试把“前端改造”和“测试补全”拆给不同会话处理。
这样读下来，收获会比单纯划重点大很多。
最后
AI 编程不会让工程复杂度消失，它只是改变了复杂度出现的位置。
以前我们主要花时间敲代码、查 API、修语法问题；现在更多时间会花在描述目标、组织上下文、设计验证路径、判断 AI 给出的方案是否靠谱。
这其实是开发者能力结构的一次迁移。
如果你最近也在试 Claude Code，建议不要只问“它能不能帮我写代码”，而是问一个更具体的问题：
我能不能把自己的开发流程，整理到足够清楚，清楚到 AI 也能参与进来？
一旦这个问题开始有答案，AI 编程就不再只是一个新工具，而会慢慢变成你的工程工作台。
参考资料：
- https://item.jd.com/10226087074659.html
)
