我是一名老程序员，广泛学习和使用过多种编程语言，编写过许多示例、项目，也出版过计算机相关的图书若干。自去年 2025 年 11 月以来，我狠狠地用 AI 写了一些软件，有时候我睡觉了，AI 还在帮助我检查、修正问题。以下是我总结的使用 AI 的经验，通过这些经验你会发现，我在扮演一名 AI 或多台 AI 的架构师或领导者。
所谓的 Claude Skills 并非简单的操作指南，其实质是高概率成功路径的固化。在外行眼中，它是加持了 AI 的使用技巧；但在内行看来，这些 Skills 是千百次失败总结出的经验。在缺少经验时，Skills 是极佳的引导；但对于有经验的人，它们若不经思考地套用，反而可能成为桎梏。我们应当学习、使用并领悟前人的 Skills，更要追求上下文无关化的复用能力。只有当我们有能力发现其不足、修正并完善它时，才算真正掌握。真正的进阶，是将 Skills 转化为逻辑本身的肌肉记忆，而非对特定 AI 技巧的依赖。
准备工作与架构设计是项目的灵魂。首先必须界定清晰的概念与用户群体，没有界定就没有聚焦。其次，要精准识别痛点：好的需求一定是已经存在的，我们不是要创造需求，而是要完善需求的满足方式与效率。在需求确定后，功能也随之固化。面对业界成百上千种方案，有了 AI 的协助，调研工作已从旷日持久缩短至几分钟，但这要求架构师必须具备挑战 AI 均值偏见的能力。例如，在面对 300MB 资源包等极限约束时，我们要引入最小可行性架构（MVA），强迫 AI 在受限条件下给出最优解，而非默认平庸的方案。
功能与方案是目标，交互与实现则是细节。当我们试图实现一个功能，即使最强大的 AI 也感到犯难或反复出错时，这反而是一件好事。AI 感到棘手，说明该领域缺乏现成的代码材料，具有极强的前沿性与先进性。像图书馆或 TODO 管理系统这类被写烂的软件，AI 分分钟即可完成，但其技术壁垒也近乎为零。我们要深思：如果代码生成得太快，我们做的东西是否真的有价值？核心竞争力应当存在于 AI 逻辑推演之外的领域知识中，例如在圣经项目中，对译名的严谨校对，对与长辈阅读习惯的深度理解。
在软件组织上，单一职责原则是对抗 AI 混乱的唯一利器。复杂的软件是由一个个积木搭成的：一个函数只干一件事，一个文件只干一类事，且其体积应短小到足以让 AI 的上下文窗口一次性完美理解。这就是上下文隔离。我们要为每个功能编写测试函数，写完一个，测好一个。不要怕功能多，自动化测试的速度远超想象。我们必须严禁 AI 在没有规则的情况下拆东墙补西墙肆意妄为。在这里，测试函数不仅是逻辑验证，更是为 AI 设立的电子围栏，防止其在迭代中产生不可控的副作用。对于 AI，有效的规则和约束，反而能让它发挥出更大的能量和价值。
清晰的逻辑远胜华丽的辞藻。AI 本质上是没有长期记忆的，所谓的记忆是我们每次通过 Prompt 帮它完成的虚假唤起。在这种背景下，doc 目录成为了项目的本地记忆核心，其重要性甚至超过 Skills。我们需要按照时间轴记录项目的起因、困难与解决方案，并维护一份 context.md 摘要。它记录了当前任务进度、已解决的坑及尚未实现的决定。这份灵魂摘要能确保我们在切换 AI 会话或面临知识折旧时，始终拥有精准的逻辑锚点。
Skills 固然重要，因为它是经验的真知；但当 Skills 与 Rule 规则结合并沉淀在项目中时，才真正成为了开发者的宝贝。在 Anti 软件中，这个名为 .agent 的目录，其重要性甚至高于项目源码本身。我们要将学到的 Skills 转化为规则，且规则中的负面约束往往比正面鼓励更有效。规则是项目的法律，Skills 是执行的战术。例如，我们可以通过在 .agent 中禁止使用三方库处理 JSON 或 UI，以达到特定目的。
构建大型项目（如跨平台应用）时，必须在一开始就定好规则并打好地基。一个成熟的架构师在选择类库时总是小心翼翼，会采用原型探针策略：在铺开业务代码前，先通过极简项目验证所有可能的核心难点。不要在后期才发现前期架构的欠缺导致推倒重来。真正的架构美学在于过程的无波无澜。
项目的可测试性与可验证性是其自动进化的基础。一个函数输入 1+1 必须得到 2，这种确定性是安全的来源。我们要允许测试对环境产生显性副作用，只要副作用是可控的、可接受的。更重要的是，我们要追求数值化与量化反馈：不要只听 AI 说已经优化，而要让它针对内存占用低于特定数值，或首屏加载快于某预设时间等硬指标进行交付。只有当功能随时可以被自动化运行并得到数值化结果时，项目才具备了持续迭代与自我修缮的能力。
2026/02/19 周四 21:13
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。