“有人打开了Miro白板。”

我知道我们麻烦了。

不是因为我讨厌图表。

我喜欢图表。

我讨厌的是打开Miro白板之后通常会发生的事。

方框出现了。

然后是箭头。

然后是更多方框。

然后有人说：

“要不我们建一个需求代理？”

另一个人点头。

“然后接一个架构代理？”

“再接一个编码代理。”

“再交给测试代理。”

“哦！还要加个文档代理。”

“别忘了PR评审代理。”

到这会儿，我们已经不小心聘请了一个AI工程部。

有趣的是？

我们依然没解决最初的问题。

我们先建了中层管理，却还没建记忆

当前AI工具生态最让我着迷的地方在于，所有人都热衷于设计专业分工。

每个提示都有职位头衔。

每条工作流都多出一个代理。

每种新能力似乎都值得在图表里多画一个方框。

与此同时，可怜的模型每次对话都要先问：

“编码规范在哪？”

又问了一遍。

普通的后端任务其实没那么刺激

说实话。

我们大多数人午饭前也发明不了新的一致性算法。

日常工作通常长这样：

  • 读一张Jira工单。
  • 搞清楚业务真正想要什么。
  • 找到相关代码。
  • 检查自己不会破坏三年前某人做出的架构决定。
  • 实现功能。
  • 写测试。
  • 开PR。
  • 因为有人觉得某个变量“读着更顺”而改名。

难的不是敲Java（或Python、C#、TypeScript、Rust……甚至上帝保佑的Visual Basic）。而是每次都要重构上下文。

恭喜，你复刻了一个初级开发者

每次新聊天都是从头开始。

“能帮我拉一下Confluence吗？”

“能打开Jira吗？”

“规范在哪？”

“这个有ADR吗？”

最后，你的AI花在和MCP服务器聊天的时间，比帮你写代码的时间还多。

恭喜。

你复刻了一个入职第一周的初级开发者。

只是和初级开发者不同的是……

……你每天早上都要把它记忆清空。

文档不该成为运行时依赖

这大概是我最大的思维转变。

Jira……还行。

Confluence……也摆在那儿。

给人类用。

但如果每次实现都要让AI不断去拉Jira工单、Confluence页面和零散文档……

……那你的文档就成了运行时依赖。

AI反复需要的东西，干脆就该存在你的知识库里。

编码规范。

架构决策。

业务术语。

评审期望。

常见实现模式。

以及“请勿在周五下午4点后改动此查询”的备注。

Markdown。

Markdown。

更多Markdown。

如果Confluence仍是事实来源，那很好。

同步它。

导出它。

嵌入它。

我不在乎怎么做。

我在乎AI能打开本地Markdown文档，而不是一天之内发起第15次MCP请求。

少拉取。

多构建。

Obsidian不是笔记本，它是记忆

人们问我为什么喜欢把Obsidian和AI一起用。

不是因为我喜欢收集Markdown文件。

而是因为Obsidian成了第二大脑。

每一次架构决策。

每一条命名约定。

每一条经验教训。

每一个业务怪癖。

每一次“我们2024年试过，结果生产环境着火了”的记录。

一旦写下来，AI就不用每场对话都重新发现它。

枯燥的部分才是胜负手

Superpowers这类工具正是我看中的地方。

老实说，把“Superpowers”换成SpecKit、Matt Pocock的工作流，或任何你喜欢的编排框架都行。

名字不重要，编排才重要。

想象一下流程。

一个技能负责收集上下文。

它读取Jira工单。

找到相关Markdown。

加载业务规格。

拉取架构决策。

找到相似实现。

完成。

下一个技能接手。

加载项目指南。

检查架构约束。

提醒模型命名约定。

突出大家总忘的业务规则。

完成。

实现结束后。

另一个技能接手。

生成PR描述。

检查文档更新。

建议发布说明。

识别缺陷。

在合适的地方提出技术债，而不是再加一个永生的TODO。

生成真正像你们团队风格的评审评论。

注意到什么没发生吗？

我们从未创建一个PR代理。

或一个架构代理。

或一个文档代理。

它们只是互相传递上下文的可复用小技能。

厉害的地方不在单个技能。

而在编排。

请别给提示起LinkedIn头衔

有些提示是这样开头的：

你是一位拥有25年企业经验的杰出首席高级软件架构师……

哥们，你只是在写提交信息。
悠着点。

现代模型已经强得离谱。

差距很少在于智力。

在于上下文。

一个好大脑胜过二十个聪明员工

我在AI辅助开发上的实验越多，就越觉得我们优化错了方向。

我们不需要另一个专家。

我们需要更好的记忆。

我们需要更好的编排。

我们需要项目知识在第一行代码写出来之前就已就位。

讽刺的是，这也是人类开发者高效的原因。

知识。

上下文。

共享约定。

而不是职位头衔。

在你再添一个代理之前……

下次有人打开Miro白板，得意地给你展示二十个用彩色箭头连接的AI代理时……

问一个问题。

“你们的编码规范在哪？”

如果答案以如下方式开头：

“嗯……它们大多散落在Confluence里……”

关掉Miro白板。

打开Obsidian。

从这里开始。

因为大多数后端团队不需要再多一个AI员工。

他们需要一个第二大脑和一组编排良好的技能。

其余的，只不过是中层管理。