AI Coding：一个项目

Tue, 31 Mar 2026 16:15:00 +0800

作为一名软件工程师，我们对AI自然不会陌生，但我如今愈发感受到软件行业正在被AI逐渐改变，甚至可能彻底颠覆，写代码这件事，正在变化。

0. 前言

最近投入了些休假时间在个人项目上，相对系统地把AI Coding工具真正用进了一个完整的软件工程过程里，体会颇多，浅分享一二。

项目中主要使用的AI工具主要有：

Codex: ChatGPT 5.4
Claude Code: Deepseek-v3.2

项目本身不只是一个demo，而是一个相对完善的软件生态，整体7万行左右包含：

前后端开发
数据库建设与定时数据同步策略
多轮需求调整、 UI及体验重构
i18n、本地化、浏览架构、交互状态等问题

这次最大的收获，不是“AI 能不能写好代码”，而是当 AI 进入真实软件工程之后，什么使用方式最有效。

1. 论功能实现，AI Coding远远强于古法编程

自AI Coding从“补全”走向“对话式协作”起，“AI能不能写好代码”这个问题的讨论已逐渐成为历史。如果说Q1内公司仓库的日常需求迭代还未让我领略到AI的强大能力，那么本次的项目的0->1是一次很好的“火力展示”。从需求沟通开始，到方案设计与讨论，以及启动代码实现，AI工具尽显专业与细致，不仅能够设计多种方案分析优劣给出建议供选择，而且对于产品形态本身也有一定的贡献。

举例来说，从整体开发能力上，前后端技术架构的搭建以及数据库、DTO的实现，AI仅用了1个多小时即完成了搭建并跑通，并且各环节单测完善、验收标准严格，这个速度着实比人工实现要快得多，古法编程的话，同样的时间恐怕尚无法写完全部的单测。并且，AI的调研和学习速度是工程师无法企及的，对于一个全栈项目，前端后端的各种框架、工具，拿来即用，这是巨大的效率优势。

另一个例子，从具体的需求和实现平衡上看，本项目可以近似理解成足球领域的“豆瓣”，但由于官方的足球数据API均为付费资源，如果实时查询将产生较大的开销，笔者和AI达成共识不在此投入成本，因此AI在数据模块进行了较为深入的方案调研，提出了多个有效控制成本的方案，经过讨论确认方案为：异步查询、批量写入、自适应调整同步器。展开来说，AI调研了主流的API提供方及其计费规则，识别到免费的额度，由于不投入成本无法cover直接查询的开销，采取异步写入数据库的方式，并且设计了自适应的轮询策略：比赛开始前1天以上、比赛开始前1天、比赛开始后至结束后1小时内等多个区段调整同步器，尽可能在免费额度内保障数据实时性。

同类的例子还有很多，总之，AI Coding的最直接的提效，就是在更短的时间内完成更高质量的开发。但这种提效存在诸多限制和规范，下文继续分析。

2. 强大的模型才能真正激发强大的工具

由于国内使用Claude Code原生模型的限制，最终选择了火山引擎的coding plan，提供的几个模型经过AI推荐，使用了deepseek-v3.2进行开发。平心而论，相比于搭载ChatGPT 5.4这种主流优秀模型的Codex，整体的表现水平存在一定的可见性的差距。

具体来说，首先笔者尝试两个工具互相review：比如spec1交给CC来实现、Codex进行review，spec2交给Codex来实现，CC进行review，并且提出review意见后会继续询问开发者是否接受。结果上很直观地看到，Codex提出的意见更加中肯、更加合理，并且能够真正找到一些编码或者设计的问题；但Claude Code大多时候仅能围绕一些规范性、扩展性等P1/P2的环节提出意见，而这些意见Codex大多情况下并不十分接受，需要笔者来补充一些编程原则确认同意某一个规范。

这个现象一方面可以理解为Codex的review能力强，另一方面也可以证明其代码实现较为符合预期导致CC无从下手挑错，但无论怎样，这说明了，在AI Coding比工程师手动编程强的基础上，通过使用更强大的模型能够取得更显著的提效。

3.要把AI当成工程协作者，进行持续的约束

在以往的需求开发中，笔者基本都采用vibe coding的模式，把AI当作一个“我说一句，它帮我做完”的“许愿池”式的工具，但这种模式对于一个大型的项目或改动很可能会失效，比如：

需求会变化
设计会反复调整
一次生成的方案往往不够稳定
代码库是有上下文和历史包袱的，AI也存在滑动窗口的长度限制导致”变笨“
模型可能在“看起来合理”和“真正对”之间摇摆，持续的提问可能导致偏差累积

所以，本次项目笔者严格采用了spec coding模式，使用AI工具结合OpenSpec驱动进行开发，在这种模式下，我们把 AI 当成一个速度很快、上下文切换成本很低、但需要持续校准的工程协作者，对于项目进行拆解并基于spec约束和跟进。整体上，进行了以下的步骤：

讨论项目需求
拆分多个Spec并定义边界
针对每一个Spec
- /opsx:explore：详细分析当前模块的实现，对齐需求
- /opsx:propose：写出技术方案和实现方式，拆解任务
- /opsx:apply：完成方案的实施和验证，在这一步后会进行多模型交叉review
- /opsx:achive：通过验证和review后进行spce的归档
持续分析产品迭代方向并补充新的Spec

在每个spec的开发中，我们要持续的给AI明确的约束，比如

这次只改什么
哪些内容不做
完成标准是什么
改完要跑哪些验证

通过以上的spec coding流程，AI工具能够有充分的上下文可验证、可复现，避免了项目出现调整时AI出现“失忆”的现象。并且每一个spec的每一个task都有迹可循，对于大型项目的管理提效明显，。另外，由于大量spec相关文档均可由AI工具进行产出，整体效率仍然较高，不会出现所谓的文档堆叠等现象，但是由于信息量较大，对reviewer提出了较高的要求。

总结来说，虽然 AI提高的是速度，但工程方法决定的是结果，即使使用了强大的AI工具和模型，如果工程方法混乱，也很难得到预期中的效率提升。

4. 最有效的节奏：小闭环、快验证、再纠偏

这次项目中最有效的工作方式不是一次性做大改，而是：

先做一个小闭环
让它跑起来
人工体验
直接指出问题
再让 AI 收下一轮

尤其对前端交互和用户体验问题，这个节奏非常有效。因为很多问题不是“代码不能运行”，而是必须靠一轮轮真实体验来校准的问题，比如：

方向不对
文案不自然
看不清
不够高级
没有产品感

另外，小量级闭环相比大量级具备更高的确定性，并且减少“幻觉”的堆积，又易于验证，而且避免了大步快走引入问题和偏移导致返工从而降效。总之，小闭环、快验证、再纠偏能够避免AI编程的提效效果被浪费。

5. 人工判断依然非常重要，尤其是产品和设计

本次开发一个很强的感受是：AI 可以给出很多“像答案”的东西，但产品方向和审美判断依然需要人来拍板。

比如：

产品方向到底应该功能深度为主还是社区化优先
提交数据是否应该拆分借口
主页导航栏设计是否是喧宾夺主
产品 logo 是不是有品牌感

这些都不是模型应该替人决定的，即使AI提出了充分的说明，但它的上下文基本都是通过和我们的沟通获取的，人的认知和判断理想情况下是要优于AI的，如果一味的点击“yes”、回复“同意”，那么工程师就成了跟着AI走的助手，而并不是把AI当作助手。对于小改动尚且可以，但大体量的项目如果工程师毫无参与，那么后续很难维护，也极易产生偏离，所以，AI编程的提效本质是给人提效，人工判断不可或缺。

6. 多Agent的分工和调度有利于整体提效

在开发过程中，笔者同时使用了两个进行coding，由于Claude Code模型相对稍差，总体的分工为：

Codex：

方案产出
主线推进及Spec撰写
主要代码实现
代码Review

Claude Code：

辅助方案产出
部分代码实现
细节代码修改及优化
方案、Spec及代码Review

在实际开发过程中，由于存在两个模型同时运行或者等待其中一个结果的情况，时间有浪费，未能充分利用开发者的全部时间及注意力。后续尝试了Codex多线程编程，同时实现多个功能等方式，但仍然有一定的等待时间浪费，且并非所有的任务均可拆分并行。因此，笔者认为，如何更好的拆分任务分配给多个AI工具执行是提效的关键因素，且这个因素取决于人。

7. 一些AI Coding技巧

持续补充

1. 先让 AI 复述需求

这是一个很朴素的技巧，其实在工作场景下很常见，当我们给AI安排任务并且这个任务并非一句话诉求的情况下，可以先让它说：

它理解了什么
哪些在范围内
哪些不在范围内
它准备先做什么

有效地执行这一步可以显著减少跑偏，毕竟AI写代码即使很快也需要等待。

2. 每次都给完成标准并要求它自己验证

这一步可以耦合进spec的定义流程，告诉AI让他显性的定义一些完成的标准，并要求它验证，例如：

页面能有效展现和跳转
数据库能够完成同步
dark/light mode争吵切换
API 返回正确

AI 很容易把“改完了”当成“完成了”，所以一定要明确“完成”的定义，AI自行执行lint、build等功能效率非常高。前置划定完成标准再结合多AI模型互相review，能够更大程度上保障执行结果不跑偏。

3. UI 问题要直接给主观反馈

对于UI类的问题，笔者的经验是直接提供主观的反馈，某种程度上，AI很难拥有主观的体验，比如

太丑
看不清
太黑
不够足球
不够高级

这类直接反馈比让AI自己优化更有效，但整体体感上仍然不够智能，比如深色模式按钮颜色太浅导致文案看不清的问题，与AI沟通多次才完成调整，可能后续提供更语义化的描述更有效（比如找到前端hmtl并发送给ai等等）

4. 会话太长时要主动总结

AI对超长上下文并不是无限稳定。从体感上，Claude Code遇到过几次超过最大窗口长度的报错，需要执行/reset命令，Codex未遇到相关报错。一个很有效的习惯是阶段性总结当前状态，把重要结论重新显式化，这个总结也可以交给AI工具执行。另外，对于需求调研和方案讨论过程中的一些思路和产出，也可以让AI工具沉淀为单独的文档，一方面可供工程师单点查看，另一方面也可以为AI工具提供总结性的上下文。

8. 总结

综上所属，本文目前的观点比较明确：

AI Coding本身代码功能提效效果足够强
模型的能力决定了AI Coding的提效上限
AI的协作规范和约束守住AI Coding的提效下限
工程师的判断力和任务组织调度是提效多少的关键因素

用一句话总结：

AI Coding已经足够强大，但它不会自动带来高质量工程，它真正带来的，是在好的工程方法之上，显著提高推进速度，而软件工程师的意义就是去用好AI Coding实现提效。

这一点需要包括笔者在内的所有AI时代下的软件工程师不断的去思考和领悟。

以上思考均为本人个人观点，难免存在纰漏，虚心向大家请教，欢迎随时交流
附：Github Repo

Codex on Sikai's Blog