当AI成为编程搭档:我们该如何重新定义“好代码”?

最近朋友圈内有几条新闻：

- 强调架构才是软件工程的核心

- 用Claude写了AMD的算子

- 强调所有人都是Agent工程师

这些碎片信息指向同一个浪潮：AI正在重塑编程的每个环节。那么，在这个‘人智协同’的新时代，那些我们曾笃信的软件工程原则，是否依然成立？什么才是这个时代更本质的追求？

架构才是软件工程的核心——翻译翻译什么叫架构？

“架构是核心”这句话我们听了无数遍，但AI时代让我们有机会重新“翻译”它。当我们说架构时，我们在说什么？本质是“选择”，以及选择背后的“权衡”。

没有哪个技术决策比另外一个技术决策高尚，正如在硬币的两面之间，没有哪一面天生更高贵，一切取决于你当前要支付的成本和预期的收益。

AI的加入，让这种“权衡-选择”的循环速度极大提升。流水不腐，户枢不蠹。优秀的架构不再是五年不变的大厦，而是在与AI的快速迭代中，保持生命力、随时可调整的有机体。

响应变化是软件工程的核心——vibe coding, to be or not?

当我们看到“用Claude写了AMD的算子”的新闻，在人和agent共存的时代，我们怎么写代码？

笔者确实也用vibe coding做类似事情，让AI帮我写dart代码。——我到今天本地dart环境都没配置。

1. **环境层**：GitHub Actions作为我的“云端编译器”，负责运行和测试。

2. **知识层**：DeepSeek作为我的“实时语言导师”，解答语法和API问题。

3. **指令层**：我编写如产品需求说明书（Spec）般精确的提示，描述功能、输入输出和边界条件。

4. **执行层**：我扮演“集成工程师”，复制、粘贴、微调，并运行CI验证。

这种模式让我甚至能跑通一些社区尚未正式发布（Pre-release）的功能。这些代码躺在GitHub仓库里，没有博文、没有教程，大语言模型并未训练过它们。这就引出了一个核心挑战：如何让AI理解这些独一无二的“现场知识”？

响应变化是软件工程的核心，人和ai共存，如何提供一个现场知识库？

当所有人都在与AI Agent协同工作时，项目的核心资产除了代码，还必须新增一项：一个机器可读、可理解的“现场知识库”。它是解决“AI不懂我项目”问题的工程化答案。

我们过去制定编码规范（如驼峰命名法），本质是为了减少团队成员间的认知摩擦和推诿。现在，这个“团队”必须包含AI。规范需要从人类约定，升级为机器可执行的指令。

比如我们做一个简单规则，一个行为必须是do(sth)——谓语(宾语结构)：

```

bird.fly()

bird.eat(bug)

```

今天有了如agent.md之后——“我”怎么保证AI能读懂？

有了这个知识库，AI生成的代码将不再是通用模板，而是高度贴合项目现状、理解特殊决策、遵守团队约定的“即战力”。它将极大减少来回沟通的成本，让人类可以更专注于更高层的设计逻辑和业务意图。

项目作者把使用相关的提示词写到agent.md里，给到AI自己测试一下，如DeepSeek，如果DeepSeek能搞定就可以了。

话总得有个头，想来想去——好好干。你不干，有的是其他AI干。

刚入行的时候，以为最大的命根是算法，于是苦刷leecode。入了行，又以为最大的不足是设计模式和工业编程的训练，一个坑一个坎过去了。紧接着三年一更新，五年一换代的技术浪潮又成了时刻逼近的斩杀线，啊，跟上时代的浪潮，又见一个叫做开源的新世界。

现在慢慢不惑了，这心头之患不在外边，而在自己对自己的要求。自己放松一点，就落后一点，自己要是对自己没要求，那就被排打在沙滩上上。

经典就是经典，那景山的老歪脖子树还站在皇宫后边，那珍妃井也还在宫里封着。

话，总得有个头啊，就用最近看到的一张图——好好干。你不干，有的是其他AI干，来收尾吧。