此帖灵感来源于：AI 产品溢出产能回收计划 & 实战任务发布 - 任务 二
在此特意鸣谢站长锤哥@terry ，以及甲方@williamlouis 的鼎力支持。

本文意在传递AI编程的体验与思路，从而帮助无编程经验，或编程经验低的人能够轻松的、果敢的通过AI赋能，实现自己的软件需求。最终人人都是产品经理。

注：基于业务的保密性，以下实际例子均为改编杜撰，仅供示例参考

1、人和AI的合作模式

对于 AI Coding，我认为有三种协作方式，人类分别扮演“董事长”、“总监”、“组长”。

董事长，只提出方向，不考虑可行性，不给具体业务，更不会给技术指导。给出的提示词类似是：

“给我做一个更好的搜索引擎，打败百度，称霸世界”

这个级别目前的AI还无法实现，估计要到梁总口中的AGI实现之后才有可能性。

总监，只给业务目标和验收标准，不管技术实现。给出的提示词类似是：

“做一个房产数据分析工具：自动采集某房产平台全部分区的房源，跟踪详情链接拿到真实挂牌地址，按区域分类；分析每套房源的价格走势和关注热度；之后我人工勾选要重点关注的房源，系统自动生成购房分析报告。”

这是目前 AI Coding 性价比最高的模式：需求里只有目标、流程和验收标准，没有任何一行技术描述，剩下全部由 AI 自己决策。这次任务的甲方需求就是这样——几段语音讲清业务流程和验收规则，全程没有一个技术名词。

组长，在总监之上再加一层项目管理：把大目标拆成小任务，逐个派给 AI，逐个验收，不合格就打回重做。比如：

“预算以用户填写的为准，不要自己计算。”
“接口限流时直接回退到备用方案，不要反复重试。”

这三种模式本质是“人类把多少决策权交给 AI”的程度。这次任务我就是“总监式推进”，全程没写业务代码，也没有干预技术选型，顺利竣工通过验收。

2、模型能力 or Harness能力

很多人以为 AI 编程好不好用，主要看工具（Harness）强不强。我的实际感受恰恰相反：决定程序质量的永远是模型本身，工具只决定生产过程中的性格偏好和严谨程度。

同一套工具、同一个需求，只是中途换个模型，结果完全不同：

模型 A：直接抓页面 HTML，正则抠数据，写一次性脚本。
模型 B：发现数据内嵌在页面结构化 JSON 里，设计了分页、去重、重试，输出可复用模块。

A、B 都能“完成任务”，但 B 的方案能稳定跑很久，A 的灵活性就很差，页面有变动就失效了。排错时差距更明显：一个只会说“重启试试”，另一个能啃完两百多万 token 的日志代码，定位根因并给出回归测试。项目中途模型升级后，产出明显上了一个台阶——工具没变，变的只有模型。

Harness 也有用，但它影响的是“怎么做”：有子代理的工具更主动探索，有计划模式的更先想后做，接入了规范、技能、沙箱和提交流程的更严谨。我用 opencode 和 Codex 时，同一模型换工具后“性格”确实会变，Codex更慢，但更严谨，openCode更快但容易走捷径。最终决定代码质量上限的还是模型。

3、VibeCoding的生产力放大杠杆

整个项目所有 AI 调用，累计 99 个会话、约 2500 万输入 tokens，按量计费的账单是 36.56 美元。但我用的是 opencodeGO 订阅——10 美元换 60 美金额度（1:6），所以实际开销要按订阅比例折算：

36.56 ÷ 60 × 10 ≈ 6.1 美元

整个项目的 AI 成本，折算下来不到 7 美元。

之所以有如此大的杠杆，个人理解，有三个原因：

1. AI 的边际成本趋近于零——同样的代码，让 AI 写十遍和让程序员写十遍，成本差几个数量级；
2. 人只做管理和验收，不做执行——我的时间花在“提需求、看结果、把关”，而不是一行行敲代码；
3. 能自动找便宜方案——需要付费数据源的地方，AI 会先用免费替代方案顶上去，而不是一上来就买几千块的 API。

所以VibeCoding 的本质，是把“编程这种高成本技能”变成“接近零边际成本的商品”，人从“生产者”变成“管理者”。

4、质量把控：用测试定义成品

先做一个简短科普。TDD（测试驱动开发）的核心不是“写测试”，而是用产品和业务的语言，先把“什么是正确的”写下来，再让代码去满足它。本质上就三步：

1. 把“需要什么、什么是正确的结果”用业务语言写下来；
2. 让 AI 写代码去满足这个清单；
3. 数次迭代打磨，找到实现这个业务目标的最优方式。

这里最关键的一点：测试必须用产品/业务定义来写，而不是用代码逻辑来写。

因为测试是“成品的定义”。如果你让 AI 照着现有代码补测试，它写出来的自然是“证明代码能跑”的测试。这就像让运动员自己给自己打分：他总能给自己打出高分，但并没有意义。

用业务定义写测试就不一样了：

测试 1：整个页面的加载时间不能超过5秒钟；
测试 2：分页能自动翻到最后一页，不遗漏、不重复；
测试 3：出现错误整个功能不能崩溃、不能闪退，记录日志；

AI 拿到这份测试，只能朝着让业务用例全部通过的方向写实现，实现写得再花哨，业务用例没过就是不合格；业务用例全部通过，才说明流程真的符合需求。TDD是把“验收标准”告诉模型；而验收标准只有以业务定义撰写，测试才真正符合业务流程。

对 vibe coding 来说，TDD 是控制权——它决定“最终成品由谁定义”：是业务流程，还是 AI 的即兴发挥。想让 AI 交付符合你业务流程的东西，就用产品和业务的语言，先把验收标准写下来。

5、后记

整个开发流程走下来，其实比想象中要顺利，且恰巧赶上了模型能力的大幅提升。deepseek-v4-flash-0731帮了我大忙。如果没有0731，可能整个项目的总成本要翻倍到15美元左右。

如果从“注意力”的时长来计算：我作为“总监”实际投入的精力，大概只有 2~3 个人/天，也就是16~24小时。而且大部分不是生产，而是试错、调研、打磨和体验。剩下的执行、排错、迭代，都是deepseek-v4-flash、GLM5.2、KIMI k3,以及opencode、Codex（现叫chatGPT）的功劳。

最后，再次感谢机会与信任。欢迎大家在评论区交流Vibe Coding的思路和想法，一起进步。

以上。