反馈控制：感知层
如果说引导层是"出发前的导航规划"，感知层就是"行驶中的实时纠偏"——无论 AI 有多自信，传感器都会用客观数据说话。
感知层的核心价值
AI 可能会错误地理解了你的意图，可能遗漏了某个边界条件，也可能在对的地方用了错的方式。这些问题不容易靠"更好的提示词"彻底消除——但可以通过自动化工具在几秒内发现。
感知层的目标不是"惩罚"AI，而是给它一个快速的、可信的反馈信号，让它在下一步就能修正。
为什么感知信号要"为 AI 优化"？
普通的错误信息是给人看的："NullPointerException at line 42"。 为 AI 优化的错误信息是这样的："ServiceA 直接依赖了 RepositoryB，违反了分层原则。请改为通过依赖注入获取，参考 src/modules/auth/auth.service.ts 的写法。"
后者不只是报错，还包含了修复方向。这是感知传感器设计的最高境界。
本项目的感知层设计
TypeScript 编译 — 最快的类型安全保障
pnpm buildTypeScript 的类型检查是本项目最底层的感知传感器。它在毫秒级内捕获：
- 类型不兼容（如把 string 传给了 number 类型的字段）
- 缺少必要的属性
- 路径别名解析错误
本项目使用 strict: true 和 nodenext 模块解析，这让类型检查更严格，传感器的"灵敏度"也更高。
AI 修改代码后，pnpm build 是第一道验证关卡。如果它通不过，说明有基础性的问题需要修复。
ESLint — 风格和潜在问题的守门员
pnpm lintESLint 在两个维度上提供反馈：
- 风格一致性：确保 AI 生成的代码和项目现有代码风格一致，不留"可以看出这段是 AI 写的"的痕迹
- 潜在 bug：捕获常见的不安全模式（如未处理的 Promise、不必要的 any 类型）
pnpm lint:fix 可以自动修复大多数风格问题，这让 AI 在"格式"层面的错误能被自动消除，让人类审查者可以专注于更重要的逻辑问题。
Jest 测试套件 — 行为正确性的证明
pnpm test测试是最直接的行为感知传感器。本项目的测试分两层：
单元测试（test/unit/）
- Mock 掉 Repository 层，专注验证 Service 的业务逻辑
- 覆盖正常路径、边界条件和异常路径
- 运行速度快（< 1 秒），适合在修改代码后立即运行
E2E 测试（test/e2e/）
- 使用真实的 PostgreSQL 数据库（需要
.env.test） - 用
supertest模拟完整的 HTTP 请求 - 验证从 Controller 到数据库的完整链路
- 在 CI 中守护接口契约，防止意外破坏
一个被忽视的关键点：AI 生成的测试需要人类审查。测试能通过，不代表测试是有意义的。AI 有时会写出"自证其明"的测试——测的是它自己的实现，而不是真正的需求。
这是感知层当前的一个未解决问题：测试质量的自动化评估（如突变测试）仍有较大提升空间。
CI 流水线 — 集成后的系统性验证
本项目有 10 个 GitHub Actions 工作流，形成了一个多层次的感知网络：
| 工作流 | 触发条件 | 验证内容 |
|---|---|---|
ci-feature.yaml | feature 分支推送 | lint + build + test |
ci-dev.yaml | dev 分支 | 同上 + 更严格的规则 |
cd-dev.yaml | dev 分支合并 | 构建 + 部署到开发环境 |
ci-release.yaml | release/* 分支 | 完整验证 + 版本号校验 |
pr-check-dev.yaml | PR → dev | 触发 ci-dev 作为门控 |
pr-check-prod.yaml | PR → main | 触发 ci-prod 作为门控 |
CI 流水线是感知层中唯一在集成后运行的部分，它能发现本地环境遮蔽的问题（如环境变量差异、依赖冲突）。
质量要尽量前移（Shift Quality Left）
不是所有检查都需要等到 CI。规则是：越快越好，越早越便宜。
pnpm build+pnpm lint在每次本地修改后运行pnpm test在影响业务逻辑的修改后运行- CI 作为最后一道安全网，不应该是发现问题的第一道关
让 AI 养成"改完代码就运行本地检查"的习惯，是减少 CI 失败次数的最有效方式。
感知层的持续演进
感知层不是配置一次就完事的。Martin Fowler 把这个过程称为**"转向循环"（Steering Loop）**：
- AI 犯了一个错误
- 找到原因：是引导层没说清楚，还是感知层没捕获？
- 改进对应的控制机制
- 这类错误在未来变得不那么可能发生
本项目的每一次 PR 描述（见发布说明）实际上都记录了这个演进过程——哪些 CI 配置被修复、哪些文档被同步、哪些错误处理被统一。这本身就是 Harness Engineering 的一个活体案例。
感知层的当前局限
坦诚地说，本项目感知层还有几个待改进的地方：
- 测试质量评估：目前没有突变测试（mutation testing），无法自动评估测试套件的有效性
- 架构漂移检测：除了靠文档审查和人工 review，还没有自动化的架构约束检查工具
- AI 审查 Agent：PR 审查目前完全依赖人工，AI 辅助代码审查尚未集成
这些是下一阶段的改进方向，也欢迎贡献。