AI 编程
在各种 AI Coding 突破与铺天盖地的 AI Coding 要抄了程序员的后路宣传下，程序员拿起 AI Coding 这把锋利的武器，开始在产品经理的鞭策下，项目经理的鼓励中，以及倒霉的 deadline 怂恿下 ，开始披荆斩棘，开疆拓土。
倒不是说 AI Coding 就是洪水猛兽，AI Coding 确实提升了开发效率，人月神话里说，经调查高级程序员的效能是低级程序员的 10 倍，如今借助 AI 可能扩展到百倍了也说不定。
开发者在这种模式下能够快速迭代和探索，但往往以牺牲代码的长期可维护性和结构清晰度为代价。
这种非结构化的开发方式虽然提升了短期效率，却可能导致技术债的快速累积，形成难以维护的“代码泥潭”，这正是传统软件开发中长期存在的问题，而 AI 的介入无疑加速了这一过程。
当我使用 Copliot 或者 Cursor，简单描述一下需求，然后代码在我的屏幕上涌现，尤其是我再加上几句贴近开发中实际需要解决需求，它贴心的考虑到并输出对应代码范式。
那种舒爽的快感简直令人难以置信（诸位应该都经历过），甚至应该配上宏伟的背景音乐。
几分钟之内，我就拥有了一个可以运行的身份验证系统、一个 REST API，或者一个可以处理我从未想过的极端情况的 Vue 组件。
但当我回头（a week later）看这些 AI 生成的代码时，我在想：“这段代码是怎么工作的？为什么要这样写？” 更糟糕的是，当我需要修改或扩展这些功能时，我发现我并没有真正理解这些代码的来龙去脉。
程序员一般不喜欢 review 别人的代码，因为你要从他的代码中反向组建拼凑出原始需求，更别说是 AI 生成的代码了。它一生成 1000 多行代码，哪有时间和精力去 review。
回头说起锋利的武器，它砍敌人很快，但也划伤自己也十分容易。
在这种情况下，应该更加注重高层次的设计和架构，而不是仅仅依赖 AI 来生成代码。
将愿景，蓝图，展望，架构，设计等高层次的东西交给人类程序员来完成，而将重复性高，机械化或者边缘化的代码生成任务交给 AI 来完成。
同时辅以再详细的划分，就和传统的模块化设计，将复杂的系统分解为更小、更易管理的部分，每个部分都有明确的职责和接口。重复上述过程，直到每个模块都足够小，可以由 AI 轻松处理。
这样可以确保代码的可维护性和可解释性，同时也能充分利用 AI 的优势来提高开发效率。
有条件的话可以和业务更紧密的合作，让业务人员直接参与到高层次的设计和架构中来，确保系统能够真正满足业务需求。
这样可以确保系统不仅在技术上可行，而且在业务上也具有实际价值。
无论怎样，AI Coding 只是一个工具，如何使用这个工具，才是最重要的。
延申
基于上述思考，以后开发产物的核心资产将由代码可能转向设计文档，架构图，流程图等高层次的设计和架构文档。
这些文档将成为系统的核心资产，因为它们定义了系统的结构、行为和交互方式。
代码将更多地被视为实现这些设计和架构的手段，而不是系统的核心资产。
甚至提示词都要比代码更重要，因为提示词定义了代码的生成方式和内容。
上述的转变意味着，未来软件开发中最稀缺、最有价值的技能，将不再是编写精巧的代码，而是撰写能够 “完全捕捉意图和价值” 的高质量规范和提示词。
这又回到了软件工程的本质问题：如何有效地将人类的意图转化为机器可执行的指令。
这要求开发者不仅要具备技术能力，还要具备良好的沟通能力和业务理解能力，能够准确地捕捉和表达业务需求。
同时拥有澄清业务的能力，其实这些应该是产品经理的职责，但现实中往往并非如此。
总结
最后总结一下：
- AI Coding 提升了短期开发效率，但可能导致代码长期可维护性和结构清晰度的下降。
- 要拥抱 AI Coding，但要注重高层次的设计和架构。
- 始终关注，聚焦能够创造价值，能够捕获需求意图的高层次设计和架构。
- 在必要时能够澄清业务需求。
- 未来软件开发中最稀缺、最有价值的技能，将是撰写能够完全捕捉意图和价值的高质量规范和提示词。
想到哪写到哪了，有些乱可能。
by:lichonglou
