最近网络一差，我突然意识到一件事：我已经不太会按传统方式编程了。

这两天我密集地用 AI 做了两个很小的项目，一个是查看大盘和资产回撤的数据页面，另一个是一个 5 到 6 个页面的小应用。项目都不大，但足够让我重新梳理一遍现在的开发方式。

编程方式的变化

2017 年刚入行时，主要靠书和搜索引擎解决问题。那时的路径很清晰：看书、查博客、翻 Stack Overflow、自己一点点拼代码。

2022 年 ChatGPT 出现后，简单实现已经可以直接问模型，写代码开始从“搜索答案”变成“对话获得方案”。

到 2025 年，我第一次用 AI 工具直接改 UI，感受已经不是“查资料更快”，而是“它真的能参与开发”。到了 2026 年，这种参与已经从辅助变成了默认工作方式。

人该负责什么

如果要把经验压缩成一句话，就是：实现可以交给 AI，但结构、边界和验收标准最好由人来定。

我现在主要把精力放在三件事上。

第一是架构拆分。比如做资产回撤页面时，我会先把系统拆成三层：数据抓取、指标计算、UI 展示。中间用 JSON 或类似的中间数据格式隔开。这样每一层都可以独立替换，后面很多实现就可以放心交给 AI。

第二是区分黑盒和白盒。有些模块我只关心结果，不关心细节；有些模块我必须理解原理，至少要能验证它为什么对。这个判断非常重要，因为它决定了你应该“让 AI 直接做”，还是“先和 AI 讨论再做”。

第三是定义验收方式。代码是不是对，不应该靠“看起来差不多”，而应该靠样例、页面效果、输出数据和边界测试来判断。

适合黑盒交给 AI 的工作

独立、可替换、容易验证的模块，很适合黑盒处理。

最典型的是抓取脚本。比如我要抓纳斯达克、上证指数、比特币、黄金等资产的历史价格，我并不关心它最后接的是哪个站点或哪个 API，只要求它能稳定拉到数据，并且每日更新时不要重复跑历史数据。这种需求直接交给 AI 效率很高，我只需要快速检查来源、跑一下结果，再补充一两个约束条件就够了。

自动化配置也是一样。像 GitHub Actions 这类配置文件，本质上是“目标明确、语法固定、出错可回滚”的工作。很多时候让 AI 直接生成，再通过实际运行验证，比自己慢慢查文档更省时间。

必须白盒处理的工作

涉及业务含义和指标定义的部分，我更倾向于白盒处理。

还是以数据项目为例，真正重要的不是“把代码写出来”，而是先确认指标该怎么算：用收盘价还是最高价，回撤区间怎么定义，历史极值按什么规则处理。这些问题如果一开始没说清楚，后面的代码写得再快，也只是更快地产生错误结果。

我的做法通常是先和 AI 多轮讨论，确认定义、样例和边界，再让它实现。实现完成后，不是先看代码，而是先看输出结果是否符合预期。对于这类模块，结果比代码风格更重要。

UI 的关键是设计约束

很多人觉得 AI 画页面的核心是提示词，比如“简洁风”“科技风”“高级感”。但实际做下来，我越来越觉得，真正决定结果的不是这些形容词，而是设计约束是否完整。

如果没有约束，AI 很容易生成一套“看起来挺像 AI 做的 UI”：配色安全、层次完整，但缺乏明确风格，改起来也会反复拉扯。

后来我发现，design.md 或 style.md 这类文件很有用。把字体、间距、颜色、圆角、布局原则写清楚，放到项目里，AI 输出会稳定很多。它的作用有点像先请来一个设计师，把规则定死，再让工程实现跟着规则走。这样 UI 阶段的工作就从“反复描述感觉”变成“按规范微调结果”。

文档才是主工作区

第二个项目让我更明确了一点：人和 AI 协作时，真正的主工作区不是代码，而是文档。

这个项目是一个 5 到 6 个页面的小应用。我先给 AI 一些设计示例和平台规范，让它输出统一的设计文档；然后再一起讨论产品文档和数据库文档，统一放到 docs 目录。接着，我让它先生成一个只有 tab 和占位页的 demo，用来确认整体 UI 风格和基础交互。

这一步很重要，因为多页面、多功能项目里，上下文再长也不是无限的。如果一开始没有一个可预览的骨架，后面边做边改，很容易返工。

轻量流程比记忆更可靠

项目一旦进入持续迭代阶段，只靠聊天记录很快就会失控。需求改多了以后，人自己都会忘记：哪些功能已经做了，哪些 bug 修过，哪些想法只是临时提过。

我后来给项目加了一个很轻量的 kanban.md，只保留 backlog、ready、done 三列。新想法、待修问题先放进 backlog；准备执行的任务放进 ready；完成后移动到 done，顺手记下完成日期、bug 原因和修复方式。如果某次修改影响了设计或实现，也要求 AI 同步更新相关文档。

这样做的价值不是“更正式”，而是让文档和代码尽量保持同步。对 AI 开发来说，这一点比流程本身更重要。

我现在的工作流

现在比较顺手的工作流大致是这样的：

先定设计文档和产品文档，再搭一个最小可运行骨架，然后把需求拆进 kanban.md，之后围绕 ready 里的事项持续推进。实现过程中，简单模块黑盒交给 AI，关键逻辑白盒讨论后再落地，最后用页面效果、样例数据和测试结果验收。

还有两个很实际的经验。

一个是语音输入。需求密集的时候，打字会变成明显瓶颈，语音反而更适合连续表达想法。

另一个是及时切换 session。大功能做完后，尽快开新会话，可以显著减少上下文污染，也能让后续任务更聚焦。

结语

AI 没有让我“不用编程”，而是把编程这件事重新分工了。

过去程序员的大量时间花在“怎么实现”上；现在越来越多时间花在“怎么拆分问题、怎么定义规范、怎么验证结果”上。代码当然还重要，但在很多小项目里，它已经不再是最稀缺的部分。