过去两年，AI 编程助手从“玩具”变成了许多团队的标配。自动补全、生成函数、甚至整段模块，都能在几秒内完成。但在代码生成越来越廉价的今天，一位资深工程师的自白式文章，给出了不同的观察：他仍然坚持手写核心代码，并且找到一种方式让 AI 帮忙，而不是代劳。
AI 的“最短路径”偏好
作者从大量“vibecoding”项目中总结出一个规律：AI 几乎总是更愿意新增代码，而不是重构现有代码。这种方式虽然能避免“AI 把我的代码库清空”这类极端事故，却带来另一个隐患——它把架构问题悄悄推迟到了未来。
比如，工程师让 AI 实现一个功能，忘记交代某个细节，AI 会自行补上。它可能拼接一段重复逻辑，或者堆上多层 if-else，但几乎不会主动说：“这个需求不改接口根本没法干净地做。”有经验的工程师通常在动手实现时就能察觉这一点，意识到小范围重构能让方案清晰得多。这种判断，恰恰是当前 AI 最欠缺的。
更棘手的是，AI 生成的代码往往格式规范、注释完整，看起来赏心悦目，但它真正存在的问题——架构错位、冗余代码、边界情况没处理——都藏在表层之下。在代码评审中，这些缺陷是最容易被忽略的。
guideme：把“怎么写”变成“改哪里”
为了对冲 AI 的“短视”，作者给自己设计了一个叫 guideme 的 SKILL.md。它的工作方式与 Claude 的 Learning Mode 有些类似，但目标用户是高级工程师，而不是新人。
这个技能不生成可直接粘贴的代码块，而是像交接入职任务一样，告诉工程师：改动涉及哪些文件、应该改什么、为什么这样改，并附上相关模块的架构概览。实现部分则完全交给工程师自己。
- 明确改动范围，提供上下文
- 解释设计动机，避免说教式的基础讲解
- 要求手工实现，让架构问题暴露出来
作者强调，亲手实现指南，正是发现审查漏掉的架构捷径的关键时刻。机器生成的代码不会“卡住”，也不会告诉你这里有个设计矛盾，但人会。
AI 编程工具的下一步
这个案例对 AI 编程工具的演进很有参考价值。它说明，AI 的价值不限于补全代码，也可以是帮助你更深刻地理解代码。与其让 AI 当“自动补全器”，不如让它当一个“带路向导”。
对团队而言，这也提醒我们：审查 AI 生成的代码时，别被表面的整洁迷惑，要额外关注结构是否合理、是否走了不必要的绕路。也许未来，更成熟的工具会在生成之前主动评估“是否应该重构”这个选项。
文章结尾的观点很务实：AI 能帮你写很多代码，但“怎么写更好看”这件事，至少目前，还是得靠人。
评论
暂无评论
成为第一个评论的人