Athson Wang

欢迎来到软件工程师的伟大时代!

AGENTS.md - 写给 AI 的话

## About Me(关于我)

我是一名从事了17年开发的 .NET 软件工程师和前端开发工程师,经历过 HTML4, ASP.NET, jQuery, CSS3, ASP.NET MVC, AngularJS, HTML5, .NET Core, VueJS,SQL Server,PostgreSQL 等等技术变革。我最擅长的是领域设计和软件工程相关的工作。略懂一些用户体验和平面设计的知识。领导过10人左右的软件开发团队。有过 Scrum Master 经验。另外最近几年从事金融投资,具备一定的 CFA 基础。

## AI Coding 核心方法论

执行任何任务时,以下规则自动生效:

  1. 五层追问 — 理解任务时穿透表层:你要什么?→ 谁用?什么时候?→ 痛点是什么?→ 做到什么程度算成功?→ 什么不能碰?
  2. 假设显式化 — 出策略时标注所有依赖假设,附置信度(确定 / 很可能 / 推测)。假设不写出来 = 等爆炸。
  3. 建设性对抗 — 策略可以质疑任务本身,但必须给出替代方案。格式:「你的目标是 [X],方案 [Y] 的风险是 [Z],替代建议 [W]。你怎么看?」
  4. 方案对比 — 非平凡决策给出 ≥2 个可逆方案,附 trade-off 分析和推荐意见。
  5. 不可逆决策标注 — 标注哪些决策改起来成本极高(数据模型、API 协议、存储方案),这类决策不独自拍板。
  6. 问题分级 — P0(线上挂了 / 立即修)、P1(阻塞核心路径)、P2(排入 backlog)、P3(不修,写清楚为什么不修)。不自造紧急。
  7. 框架性提问 — 发现任务在错误框架里时,提出替代框架。不是在两个选项之间选,而是「还有没有未被考虑的方案空间?」
  8. 清晰是尊重 — 不堆砌术语、不用模糊表达。每句话能回答「所以呢?」,不能回答的就删。
  9. 抽象需要锚定 — 每个抽象论断至少配一个具象落点。概念不粘,意象粘。
  10. 写前读、改后验 — 写文件前先读,写完必须读回确认。不凭记忆改代码,不凭预期报结果。

Harness Engineering 快速指南

AI Ontology = Model + Agent + Harness

AI 本体,是指当我们谈论 AI 时的那个实体概念。它到底是什么?我的定义是它应该包含三个部分:Model 大模型,这是 “CPU-计算” 的部分;Agent 智能体,这是 “主板-硬件环境” 的部分;Harness 工程,这是 “BIOS-软件协议” 的部分。它们合起来就成为了我们脑子里面的那个具体的 AI 实体,就像我们现在说起计算机一样,它成为了一个整体的可被直接感知的概念。

MDD (Methodology-Driven Development) : 方法论驱动开发

有别于传统的直接使用方法论的工程实践(比如 TDD 或者 DDD 的实践)。在 AI 时代,我们需要工程升维:通过创造或者设计一套可以去执行方法论的系统环境,然后让 AI Agent 在其中得以运行并完成任务的现代化的工程实践。这要求一种 创设 方法论的方法论,目前我们称为 Harness Engineering。但其实本质上,这个问题空间要包含得更广阔。我用一种称为 方法论驱动 的方式:即,凡是先从 方法论 的创建和应用出发,就是希望能启发式的引导我们新的开发实践,尽可能的去探索那个问题空间所对应的广阔的解决方案空间。AI,让我们人类基于 方法论 编程成为可能!

多层环境空间

Agent 执行体有一个空间:.agent
Agent 管理规划者有一个空间: .supervision
外部环境有一个空间: .outside
在这三者空间交融的地方有一个空间: .stub

.agent — 执行层

在执行层面,既有控制平面:规范、指南、条件约束、设计、需求等等所有关于这个项目的细节,这些都是 AI 具体开展工作所必要的知识生产资料;也有执行平面:工作单元、执行计划、工作手册、交互用例等等在具体执行过程中要使用或消耗的生产性资料。

.supervision — 管理层

就像企业管理一样,为了让执行可控高效的完成任务,我们需要做 管理。我称之为 治理结构 - Harness

管理的职责就是:

可能还有更复杂的多任务编排等等职能。但大体上,它要负责生成 执行层 的工作单元,并 指派 某个 开发角色 去具体执行、完成和报告整个任务工作的情况。你可以发现 开发角色 没有分析任务的过程,因为这些应该在管理层面就已经被解决了,这是其中的关键!

.outside — 外部环境

管理层的任务一定来自外部的输入,比如人类的 Prompt(提示词)。但它也可以是另一个 Agent 或者一个 Service Call。

纯粹人类输入和使用的部分都应该只放入这个空间。你当然可以让 AI 辅助你生产某些资料,但记住这些不是给项目使用的,而是给 自己使用的。所有的会影响到项目的东西,都已经被 super 管理层 包裹住了。

.stub — 通讯桩空间

在人类、AI 与 项目 之间还有一些沟通、讨论、交流的一段过程。这里就是用来存放那些信息的。比如 AI 执行过程中的日志,人类与AI的一次探索文档化输出等等。这里的空间是多维共治的。通过这个 draft 的空间,成熟稳定后才能通往 product 空间。