- Published on
每次用 AI 做完东西，我都会问：这还算我做的吗？
- Authors
- Name
- Allen Wang
写于某个周六，跟 AI 聊了一整晚之后
- 一、一个让我卡住的需求
- 二、同事一句话把我打回原型
- 三、然后我盯着屏幕看了很久
- 四、L1 到 L5 —— 一个程度量表
- 五、第一次修正：临时性 vs 生产性
- 六、第二次修正：领域深度 vs 领域宽度
- 七、真正的判断尺：三条
- 八、但——AI 越强 = 不用懂代码？错
- 九、糊弄是合法选择，但别既要又要
- 十、当所有模块都"乐高化"——我还剩什么？
- 十一、新定义：什么叫"在写代码"
- 十二、但——"写判断"有一个隐含前提
- 十三、写在最后
写在前面
这篇文章不是教程，是一次自我审问。
其实这个问题一直跟着我——每次用 AI 做完一个东西，我都会问一句：这还算我做的吗？
不是某个具体项目带来的困惑，是这几年一直盘旋的背景音。
只是这次，它被一个同事的轻量方案，逼到了我面前。
我刚从一家传统大公司跳到一家电商公司，入职第二周。接到一个正经需求，本能想上一套重型方案；同事随手说了个轻量做法——两周跑通，效果比我预想的好。
然后我盯着屏幕看了很久。
因为我又一次发现——我好像一行核心代码都没写，但这东西是我交付的。
这到底算不算"我做的"？
还是说——这个问题本身，就问错了方向？
一、一个让我卡住的需求
需求很简单：公司内部要一个合规知识库。
一堆内部规章（docx / pdf / ppt / xlsx），法务和业务部门需要查询。数据源之后还会迁移到飞书云文档，要支持增量同步。对外形态希望是 MCP，这样 CherryStudio / Claude Code / 内部系统都能用。
听起来很常见的需求吧。
我坐在工位上，第一反应就跳出来了：
- LangChain 做 RAG 编排
- RAGFlow 做文档解析 + 分块
- 自建 embedding + reranker pipeline
- 向量库（Milvus 或 Qdrant）
- 业务 API 层包一层
- 最后再套个 MCP server
我脑子里已经在画架构图了：6 个组件、3 周开发、2 周联调，一个月上线。
然后我去问了同事。
二、同事一句话把我打回原型
同事看了一眼需求，说：
"用 ContextWeaver 挂一下就行了。它本来是做代码检索的，但核心就是 hybrid search + RRF + reranker + MCP server——我们把所有文档都转成 md 喂进去，一样能用。两周能上。"
我愣了一下。
这里得插一句背景——ContextWeaver 的 README 第一行写着：
"Semantic Code Retrieval for AI Agents"
它原本是给 AI 代码助手做代码检索用的，不是给文档检索做的。它的白名单扩展名里文档类甚至只有一个 .md。
同事没在"RAG 工具库"里找方案——他是直接识别了它的抽象能力（语义检索 + hybrid + RRF + Reranker 这一整套工程深度），然后意识到：
只要输入格式统一成 md，这套能力可以跨域迁移到文档检索。
这不是"找现成方案"，是"看到工具的本质，再把它借到自己的场景"。
当时我没意识到这一层——我心里第一反应只有——
这不是糊弄吗？
没有 LangChain、没有 RAGFlow、没有自建 pipeline，一个开源项目挂一下就交付了。连向量库选型都没想过。
这在我之前的工作环境里，是要被 review 打回的。方案评审会上会有一堆问题：
- "如果 ContextWeaver 哪天不维护了怎么办？"
- "我们对召回率的控制力呢？"
- "为什么不自建 pipeline 好迭代？"
- "万一需求扩展了这个架构撑得住吗？"
但我还是按同事的思路试了。
因为……我才刚入职，先别急着表达意见。
三、然后我盯着屏幕看了很久
两天跑通。
踩了几个坑都是配置层的坑，不是架构层的。
A/B 测试跑了 10 个 query，默认参数 8.7/10，调参后反而 8.4/10（调参收益在这个数据规模下基本是噪声）。
挂到 CherryStudio，尝试用了一下——好使。
然后我在 ContextWeaver 之上，包了一层自己的业务封装：飞书同步 worker、增量检测、HTTP API、权限管理、日志监控。这层是我自己指挥 AI 写的。
但核心的检索能力？—— 来自 ContextWeaver。我一行都没改过它的核心代码。
我盯着 CherryStudio 里的回答看了很久。
这算我做的吗？
四、L1 到 L5 —— 一个程度量表
我试着给自己画一把尺子。
"自己写代码"这件事，我分成 5 个层级：
| 层级 | 你做了什么 | 算你写的吗？ |
|---|---|---|
| L1 | 输入"写个 Todo App"，AI 原样输出 | ❌ 不算 |
| L2 | 指定了技术栈（"用 React+TS+Zustand"） | ⚠️ 勉强 |
| L3 | 定了模块划分、数据模型、状态方案 | ✅ 算 |
| L4 | 手写核心逻辑，AI 写辅助代码 | ✅ 算 |
| L5 | 从架构到每行实现全手敲，AI 只用来查文档 | ✅ 算（2026 年已经少见） |
看起来挺清楚吧。
然后我试着把自己这次的工作往上套——
- ContextWeaver 核心：我是 L1（直接用）
- 飞书同步 worker：我是 L3（定了架构、数据流、失败重试策略，AI 写实现）
- 业务封装层：我是 L3-L4（核心逻辑我设计，代码 AI 写）
- 整体系统集成：我是 L3（知道每块是干嘛的，能解释为什么这么拼）
所以这个项目整体，我大概在 L3。
这个结论让我有点意外。因为我原本觉得自己这次是"没怎么做事"——但按这把尺子，我其实做了不少决策。
只是决策不体现在代码行数上。
五、第一次修正：临时性 vs 生产性
但这把尺子有个问题。
一个反例马上跳出来：图像处理我根本不懂。有时候我给 AI 一堆样本，让它写代码，我只看输出图片对不对——这算什么？
这不是 L3。我连模块划分都说不清，我就看"图出来是不是对的"。
这按 L2 算，那是不是就"不够"了？
我想了想，其实不是。
我给量表加了第一个维度——临时性 vs 生产性：
| 维度 | 临时 | 生产 |
|---|---|---|
| 用完就扔？ | ✅ | ❌ |
| 长期维护？ | ❌ | ✅ |
| 别人在用？ | ❌ 只有自己 | ✅ 其他人 |
| 要迭代？ | ❌ | ✅ |
临时任务里的 L2，完全合理。 我为什么要为一个"把 500 张图加水印"的脚本学 Pillow？跑完就删。
但生产任务里的 L2 是警戒线。 因为：
- 你的样本可能没覆盖生产数据里的边缘情况
- 性能衰减你看不见（AI 可能写 for 循环而不用 numpy 矢量化，慢 100 倍你都不知道）
- 依赖升级你兜不住（Pillow 某版本 API 改了）
- 维护时你改不动（客户说"边缘柔和一点"——你知道那叫"高斯模糊 sigma 参数"吗？）
这个维度让我对自己这次的工作重新评估了一遍——生产任务 + L3，合格。
六、第二次修正：领域深度 vs 领域宽度
然后我又想到另一个事。
没有人能在所有领域都 L5。
我自己之前独立做过一个 LangGraph 的 18 节点系统，是我最接近"独自完成"的东西。但即使在那个项目里——
| 模块 | 我的层级 |
|---|---|
| 核心业务（LangGraph 编排） | L3-L4（架构我设计，节点实现 AI 辅助） |
| 前端 UI | L2（几乎看不懂，让 AI 写） |
| Docker + Cloudflare Tunnel | L2（跟教程走） |
| PostgreSQL 性能调优 | L2（遇到问题再查） |
这才是真实的——连我"最懂"的项目，也没有任何一块到得了 L5。
但这完全正常。 在核心领域 L3-L4、在边缘领域 L2——这叫深度分配，是工程师的生存智慧。
问题不是"你什么都懂"，而是——
你要能说清哪些是你的核心领域，哪些是你主动选择的"放弃领域"。
"全都不懂"的人，和"选择性不懂"的人——差别巨大。
七、真正的判断尺：三条
折腾完这些维度之后，我回到三条最简单的判断。
不管用了多少 AI，只要这三条都打钩，就是你的：
你能说清这个系统「为什么」这样设计吗？ 不是每个 if-else，是整体架构的逻辑。
出 bug 时你能定位到「哪个模块」出问题吗？ 不是你亲手修好它，是先找到它。
有人问"为什么不用 X 方案"时，你答得出理由吗？ 选型依据，权衡过什么。
三条都打钩 → 是你的。
至于具体某行语法是不是 AI 生成的——不重要。
按这把尺子，我那个合规知识库——
- 为什么不用 LangChain？✅ 答得出（过度工程）
- 为什么选 ContextWeaver？✅ 答得出（工程深度够 + 开箱即用）
- 为什么这样设计飞书同步？✅ 答得出（增量 + 幂等 + 原生导出 MD）
- 出 bug 时能定位吗？✅ 能（8 个踩坑我都记在日志里）
这个东西是我做的。
只是我做的是系统，不是代码。
八、但——AI 越强 = 不用懂代码？错
这个框架让我觉得轻松了一下。但马上又跳出来一个更危险的念头：
"反正 AI 能力只会越来越强，我只要会 prompt 就行了。"
这是 2026 年很多人的误区。
老实说，我一开始也差点这么想。但仔细一想，这是错的。
AI 越强，不是让"不懂的人"越吃香——是让"懂的人"越稀缺。
想象一下：
- AI 达到初级工程师水平 → 初级被淘汰
- AI 达到中级工程师水平 → 中级被淘汰
- AI 达到高级工程师水平 → ……
这时候，能 review AI 输出、能在 AI 犯错时兜底、能和 AI 协作做更高层判断的人——更值钱。
因为 AI 水平越高，能驾驭它的人越少。驾驭的前提是懂。
"会 prompt"从来不是能力。 "能判断 AI 输出对不对"才是。
所以我给自己定了一条最低线——L3 是底线。
不是每行都看，但这四件事必须做到：
- 架构级看懂（数据流 / 模块边界）
- 核心链路看懂（主业务逻辑）
- 遇到 bug 能 debug 到根因
- 知道用了哪些依赖、哪些服务
守住这些，AI 写多少都不是问题。 守不住——那就不是你在使用 AI，是 AI 在替代你。
九、糊弄是合法选择，但别既要又要
写到这里，可能有人想反驳：
"打工大部分人都在糊弄交付，谁那么认真？工资还不是拿一样的。"
这话不假。
糊弄确实是合法选择。 没人规定每个人都要追求职业精进——有人想稳稳打工、把生活重心放在工作之外、不 care 35 岁焦虑，这完全 OK，是成熟的人生选择。
但最难受的状态既不是糊弄派、也不是认真派——是夹在中间的："一边选糊弄、一边焦虑「我是不是在糊弄」"。
我前几周就在这个状态里。
接到一个能交付的需求，用了一个能跑通的方案，但内心一直有声音在审判："这不算你做的""你只是 prompt 工程师""你在糊弄"。
后来想明白了——选哪个都行，但心里要清楚自己在选什么。
否则你既得不到糊弄派的轻松，也得不到认真派的踏实。
这是夹在中间最大的代价。
十、当所有模块都"乐高化"——我还剩什么？
写到这里，一个更深的问题跳出来了——
如果以后 AI Agent 的每一块都可以"挂一下就行"：
- RAG 外包给 RAGFlow / ContextWeaver
- 记忆 外包给 Mem0 / Letta
- Context 管理 外包给 Cognee / LangMem
- Agent 编排 外包给 LangGraph
- 工具调用 外包给 MCP servers
- 模型 外包给 Anthropic / OpenAI
- 甚至 "编排的编排" 外包给 Dify / n8n / Coze
那我还剩什么？
这是一个越来越真实的问题。我给它起了个名字："AI Agent 的乐高化"。
想了想，能剩下的是这些无法外包的东西：
- 选哪些积木（Mem0 还是 Letta？RAGFlow 还是 ContextWeaver？）
- 怎么拼（架构 / 数据流 / 职责划分）
- 为什么这样拼（权衡 / trade-off / 业务约束）
- 出问题找哪块（debug 能力 / 故障定位）
- 业务适配（通用模块怎么改得贴合你的场景）
- 评估和验证（你怎么知道这玩意儿 work？）
这六条——就是 2026 年程序员的新价值锚点。
越往后看，"手写一段 RAG 代码"的价值越低，做这些判断类工作的价值越高。
这对一部分人是解脱—— 不擅长手撸算法的人，可以在"选型 + 判断 + 组合"上找到新的立足点。
这对另一部分人是危机—— 那些只习惯"手写代码求掌控感"、不习惯做判断的人，以后会越来越找不到位置。
十一、新定义：什么叫"在写代码"
这次经历让我对"写代码"这件事重新理解了——
旧定义：手敲了多少行。 新定义：做了多少判断、承担了多少决定、理解了多少为什么。
AI 把"手敲"这件事解放了。这不是让我们变成"提示词工程师"——是让我们有机会做更高维的事情。
2026 年的程序员写代码——不是少了，是换了一种写法。
但换法的前提是——你真的在做"更高维的事"，而不是把 AI 的输出当黑盒原封不动交上去。
前者叫升级，后者叫退化。
差别在于你自己知不知道。
十二、但——"写判断"有一个隐含前提
写到这里，我必须诚实交代一件事。
我现在能守住 L3，是因为我之前有过 L4/L5 的经验。
这些"判断"不是凭空来的，是过去的代码经验沉淀下来的。
所以"写判断而不是写代码"这个新定义成立——
但它有一个隐含前提：
你得先写过代码，才有资格只写判断。
如果一个人从入行第一天就只在 L3 工作，从没认真读过一个系统的核心代码、从没手动 debug 过非典型问题——
他的"判断力"其实是悬空的。
- 不是判断，是模式匹配
- 不是理解，是复述 GitHub 的 README
- 不是选型，是信任 ChatGPT 的推荐
这是 AI 时代最大的隐忧——
新人可能再也没机会建立底层直觉了。
他们一上手就是 prompt + AI 生成 + 黑盒交付。看起来跟我们做的事一样，但判断力的底子是空的。
而且更糟糕的是——他们自己往往不知道底子是空的。
因为 AI 生成的代码看起来都对、跑起来都对、benchmark 都通过。只有当你需要做「非典型判断」的时候，你才会知道自己有没有底。
那时候，已经晚了。
所以——
- 如果你是已经写过代码的"老程序员"，L3 是合法的舒适区。
- 如果你是 2026 年才入行的程序员，不要直接停在 L3。哪怕只是为了未来更高质量的 L3，你也得先经历 L4/L5。
底层经验是一次性的成长窗口。错过了，就是终身的能力空心化。
十三、写在最后
说回那个合规知识库。
我到现在也没读过 ContextWeaver 的核心源码（那是周末 TODO）。我甚至不完全理解 RRF（Reciprocal Rank Fusion）数学上到底怎么融合的。
但我知道：
- 这个需求用它对
- 它跑出来的结果我能验证
- 出了问题我能找到模块
- 以后要换方案我能评估迁移成本
这四条加起来，让我能在周一自信地交付。
我不是这段代码的作者。但我是这个系统的作者。
这是 AI 时代程序员的新身份——我们写的不是代码，是判断。
至于我那个"接到需求就想上 LangChain"的本能——
那不是品味，是路径依赖。我从上一家公司带来的习惯——没错，但不适合这里。这里要的是"两周跑通"，不是"三年演进"。
同事那套"开源项目挂一下"的思路，在这个场景里是更高级的判断。
所以写到最后我发现——
我一直纠结的**"这还算我做的吗"**，可能问错了方向。
真正的问题是三个：
- 思维惯性——从上一家公司带来的"精雕细琢才算做事"的审美
- 舒适区——只有在"重型架构"里我才感觉自己在做事
- 公司匹配度——不同公司本来就需要不同的工作模式
所以"这算不算我做的"——这个问题没有统一答案。
在上一家公司，它是"是"；在这里，它也可以是"是"，只是我的作品定义要跟着换。
- 以前我写代码，现在我做判断
- 以前我手撸架构，现在我选型 + 组合 + 验证
- 以前"产出"等于"代码行数"，现在"产出"等于"能跑的系统"
是我自己还没切换过来——不是这份工作不够"正经"。
—— 写于入职第二周的周六深夜，跟我的 AI 聊了一整晚之后。
愿我们都能分清：什么是应付、什么是思维惯性、什么是做自己真正认可的事。