AI Coding不是不会代码就能做
这两个月，我明显把自己的 AI coding 工作切到了 Codex 里。
过去我也用过一些常规工具。
但最近越来越多真实项目，都是在 Codex 里推进。
Codex 加上 GPT-5.5 这一类顶级模型，已经是非常强的编程 AI 组合。
很多时候，它不只是帮你写代码。
它会读项目、拆任务、改文件、跑命令、修问题，再把结果交回来。
但我今天想说的，不是哪个工具更强。
我真正想说的是另一件事。
普通人绝对不是随随便便就能把 AI coding 做好的。
不是因为模型不行。
也不是因为工具不够强。
恰恰相反。
模型越强，越能暴露一个问题。
你缺的不是“写代码”的能力，而是软件工程常识。
很多人听到 AI coding，会有一种错觉。
好像以后不会写代码也能做软件。
这个判断只对了一半。
不会写代码，确实可以开始做东西。
但写代码和软件工程是两回事。
写代码，是把某个功能实现出来。
软件工程，是把一个需求从想法变成可交付、可维护、可迭代的系统。
如果没有软件工程训练，没有基本流程常识，对研发流程完全不清楚，你很难做出真正能用的东西。
你可以做一个页面。
可以做一个演示。
可以做一个看起来很像产品的小玩具。
但生产级的东西，不是“能打开”就够了。
它要能被真实用户使用。
要能持续迭代。
要能定位问题。
要能上线、回滚、测试、验收。
这些都不是 AI 自动帮你兜底的。
所以我反对那种“无需基础就能做出好产品”的说法。
AI 可以降低门槛。
但它不会取消门槛。
公开数据也在提醒这件事
OpenAI 在 GPT-5.5 的发布材料里，把它称为最强的 agentic coding model。
Codex 的工作方式也很清楚。
它不是简单生成一段代码。
它会围绕真实项目读文件、改文件、运行命令、检查结果，再把过程反馈给你。
这说明什么？
最顶级的 AI 编程工具，本身也在模拟软件工程流程。
不是绕开流程。
而是把流程自动化一部分。
图1：顶级 AI 编程工具真正强的地方，是进入工程流程，而不是替你跳过流程。
Stack Overflow 2025 开发者调查里，有一个数据很值得看。
开发者使用 AI 的比例越来越高。
但对 AI 输出准确性的信任并不高。
调查显示，主动不信任 AI 准确性的开发者，比信任的人更多。
这不是开发者保守。
这是工程常识。
代码不是作文。
错一个边界条件，可能就是线上事故。
少一个权限判断，可能就是安全漏洞。
漏一个异常处理，用户就会在某个奇怪场景里卡死。
DORA 2024 报告也提到，AI 能提高个体生产力和流畅感，但软件交付的稳定性和吞吐仍然依赖小批量、测试等基本功。
OWASP 对 LLM 应用风险的提醒也很直接。
提示词注入、不安全输出处理、敏感信息泄露、过度授权，这些都会出问题。
所以你看，真正严肃的人从来不说“有 AI 就不需要工程”。
他们说的是：AI 进入工程以后，工程纪律更重要。
普通人最容易错在哪里
我见过很多人做 AI coding。
一开始都很兴奋。
他说，我想做一个插件。
我想做一个智能体。
我想做一个网页应用。
这都没有问题。
问题在下一步。
他不知道需求是什么。
也不知道怎么把需求拆开。
更不知道怎么判断 AI 写出来的实现路径是否合理。
这才是普通人真正卡住的地方。
不是模型不够聪明。
是你不知道什么叫正确的工程过程。
这里说的软件工程常识，不是让你去背代码。
也不是让你突然变成架构师。
它更像一套做事的基本顺序。
第一，你要定义清楚需求。
第二，你要拆解功能边界。
第三，你要知道产品交互怎么设计。
第四，你要让 AI 逐个实现。
第五，你要逐个测试。
第六，你要回归验证。
第七，你要验收上线。
这些步骤看起来朴素。
但真正差距就在这里。
图2：AI 可以参与编码，但不能替你消灭需求、拆解、测试和验收。
你不懂需求，AI 就会很勤奋地跑偏
AI coding 最大的危险，不是 AI 不干活。
恰恰相反。
它太能干了。
你给一个含糊需求，它也会很认真地完成。
问题是，它完成的可能不是你真正想要的东西。
这就像你请了一个非常快的施工队。
但图纸没画清楚。
施工越快，返工越痛。
所以我一直强调，普通人不一定要懂代码。
但一定要懂需求。
你要知道你到底要做什么。
用户是谁。
场景是什么。
输入是什么。
输出是什么。
边界在哪里。
哪些东西先不做。
哪些东西必须做对。
如果这些都说不清，AI 只会放大你的混乱。
一个很典型的例子：页面内容要不要一次性注入
比如我最近做插件时，就遇到一个很典型的问题。
我在处理一个 AIHR 插件。
这个插件需要在浏览器侧边栏里和页面内容协同工作。
插件需要理解页面内容。
那是不是应该一次性把页面里所有内容都提取出来，然后直接注入到提示词里？
很多人第一反应是：当然啊。
材料越多，AI 越懂。
但这个想法很危险。
因为用户打开插件，不一定只问当前页面。
他可能问页面里的内容。
也可能问一个延伸问题。
也可能让你基于页面做分析。
还可能完全问一件别的事。
如果你把页面内容全部塞进提示词，系统就会被页面绑死。
它很容易只围着一个材料转。
token 也会浪费。
上下文还可能被污染。
图3：AIHR 插件调试现场。真正的问题不是“会不会写代码”，而是如何判断页面内容什么时候该注入、怎样隔离、如何路由。
图4：页面信息不是越多越好，关键是该什么时候取、取多少、怎么隔离。
更好的设计是什么？
你要先想交互层。
用户是在页面对话里问吗？
要不要让用户选择“基于当前页面回答”？
要不要做自动路由？
要不要先摘要页面，再把摘要作为上下文？
要不要把页面内容和用户问题隔离成两个上下文块？
要不要在回答前判断问题是否真的需要页面信息？
这些问题不是代码语法问题。
这是产品设计问题。
也是软件工程问题。
换句话说，AI 能帮你把某个方案写出来。
但它不能替你判断这个方案是不是对的。
你不理解这些，AI 给你写出来的方案可能看起来能跑。
但一到真实使用，就会露馅。
AI coding 必须小步走
很多普通人还有一个习惯。
一上来就把全部需求丢给 AI。
让它一次性全做完。
这很容易出问题。
真正严肃的做法，是先搭大框架。
然后逐个功能往下做。
一个功能做完，就测一个功能。
一个场景跑通，再做下一个场景。
每次改完，都要回归。
每个关键节点，都要验收。
这件事很考验你对软件工程的理解。
因为 AI 在实现过程中，可能采用一条看似合理、但长期维护很差的路径。
它可能把逻辑写死。
可能绕过权限。
可能把状态管理做乱。
可能把临时方案写成核心逻辑。
也可能为了让测试通过，偷偷改掉真正的需求。
如果你没有基本判断力，你根本发现不了。
我反对“无需基础就能做出好产品”
我很反对一种说法。
说普通人完全不需要基础，就能靠 AI 做出很好的 Web 产品。
我认为不可能。
你可以做出一个样子。
可以做出一个 demo。
甚至可以发朋友圈。
但要做成能交付、能上线、能被别人长期用的东西，必须接受基本训练。
这个训练不是去读一本厚厚的代码书。
而是跟着真实项目走一遍。
从需求到拆解。
从拆解到实现。
从实现到测试。
从测试到发布。
从发布到复盘。
你走过一次，就知道软件不是“生成一下”那么简单。
上线也是一样。
很多人对发布完全没有概念。
域名怎么绑。
环境变量怎么配。
权限怎么管。
日志怎么看。
失败怎么回滚。
出了问题怎么定位。
这些 AI 都可以帮你做。
但如果你完全没有概念，它会消耗大量 token 带你绕路。
最后你还是不知道自己做了什么。
我自己的体感
我不是软件工程专业出身。
但我一直在干软件工程相关的事。
我一直做 AI 产品。
也一直在做需求、做产品、做流程。
从开始到现在，我做 AI coding 已经一年多，接近两年。
自己做过的项目超过 300 个。
发布过的产品也超过 300 个。
其中有五六个，是真正交付给市场或别人使用的产品。
从简单插件，到智能体。
从原生智能体，到高代码智能体。
从小工具，到智能体平台。
这些我都做过。
也正因为做得多，我才越来越不相信“轻轻松松就能做生产级软件”。
越高级的东西，越依赖条件。
依赖需求清晰。
依赖流程稳定。
依赖上下文管理。
依赖测试和回归。
依赖发布和运维。
依赖你对问题的判断。
AI 可以让这些过程变快。
但不会让这些过程消失。
普通人应该怎么学
如果你真的想做 AI coding，不要先去学语法。
也不要先去追工具。
你应该先学一套基本作业法。
而且要跟专业的人学。
这里的专业，不是指他会不会手写很多代码。
而是他能不能把需求、产品、研发、测试、上线这一套流程讲清楚。
很多专业程序员当然很厉害。
但他们也不是天生就会教。
很多时候，他们默认你已经懂很多东西。
默认你懂需求。
默认你懂分支。
默认你懂测试。
默认你懂部署。
结果就是，他自己会，但教不会你。
普通人真正需要的，不是被扔进代码海里。
而是有人带你把完整流程走一遍。
1把需求写清楚：目标、用户、场景、输入、输出、边界。
2把功能拆小：先框架，后模块，最后细节。
3让 AI 分步实现：一次只做一个明确功能。
4每一步都测试：不要等全部做完再看。
5上线前做验收：路径、权限、异常、日志、回滚都要看。
这个过程看起来慢。
但它其实更快。
因为它减少返工。
也减少 token 浪费。
更重要的是，它能训练你的判断力。
AI coding 真正稀缺的不是提示词。
是判断力。
如果你想真正学会，就要跟走过这条路的人学。
跟我学的价值，也在这里。
我不是让你变成程序员。
我是带你把 AI coding 背后的软件工程常识补起来。
最后留个钩子
最近我围绕 AI 产品设计、AI 流程管理变革和咨询交付，做了不少插件。
其中有一个叫“AI 咨询”的插件。
它可以辅助做企业 AI 转型诊断、咨询方案拆解、场景梳理和管理者陪跑设计。
感兴趣的朋友，可以找我拿。
领取条件很简单。
把这篇公众号转发到朋友圈。
注意，要设为完全公开。
不要设“仅自己可见”。
不要设分组可见。
就是完全公开。
转发后截图给我，就可以找我拿这个插件。
如果你也想系统学 AI coding，不是学语法，而是学真实项目怎么从需求跑到上线，也可以来聊。
我会带你补软件工程常识，带你理解需求、拆解、实现、测试、上线和复盘。
不要迷信工具。
先把工程常识补上。
几句可以单独转发的话
AI coding 做不好的原因，很多时候不是不会代码，而是不懂需求、不懂流程、不懂验收。
写代码和软件工程是两回事。AI 会写代码，不代表你会做软件。
AI 可以替你写代码，但不能替你定义产品边界。
越强的模型，越会放大你的需求质量。
生产级软件不是能打开就行，而是能测试、能回归、能上线、能维护。
关于詹老师
我是詹老师，长期聚焦 AI 产品设计和 AI 流程管理变革。
我不是软件工程专业出身，但一直在做需求、产品、流程和 AI 项目交付。
过去一年多，我持续用 Codex 和顶级模型做 AI coding，完成过 300 多个项目和产品验证，也交付过真实可用的插件、智能体和平台类产品。
我更关心的不是“AI 有多热”，而是普通人如何真正补上软件工程常识，把 AI coding 从玩具做成可交付能力。
如果你正在推动企业 AI 转型，或者想把 AI coding 学成一套可复用的做事方法，可以来找我聊。
参考资料：OpenAI GPT-5.5 与 Codex 官方材料、Stack Overflow 2025 Developer Survey、DORA 2024 Accelerate State of DevOps Report、OWASP Top 10 for Large Language Model Applications。文中对项目数量和交付经验为作者个人实践表述。