内部技术分享 / 2026-04-19

PAS AI 全栈
用软件工程思维
做 AI 辅助开发

不是调 prompt，是把 AI 当成团队成员，
给它一个完整的工作环境。

NickPAS 项目 · 30 min
#AI #HarnessEngineering #SoftwareEngineering

agenda.toml

今天聊什么

01背景：AI Coding 的三次进化~3min
02Harness Engineering 是什么~3min
03三个工程原语 + 四层反馈~5min
04SKILL · OpenSpec · MCP 落地~10min
05多 Agent 并行 + AI Code Review~3min
06代码规范 + AGENTS.md~2min
07CodingAgent 工具库大盘点（87个）~5min
08实际效果~3min
09全流程还差什么~2min
10踩过的坑：Vibekanban / Openclaw+Tmux~2min
11局限性：Human in the Loop~3min
12Q&A + 总结~3min

// background

AI Coding 的三次进化

Prompt Engineering

早期：怎么让模型听我的话？
核心技能：写好提示词。

2022-2023

Context Engineering

中期：怎么给模型最好的上下文？
核心技能：RAG、上下文压缩。

2023-2024

Harness Engineering

现在：怎么让 AI 靠谱地工作？
核心技能：软件工程 + AI 协同。

2025 → now

Harness 的本质：不是新技术，是软件工程全流程自动化

// what-is-harness

Harness Engineering =
让 AI 靠谱工作的软件工程

以前：人写代码 → 人跑测试 → 人 Review → 人部署

现在：AI 写代码 → Harness 兜底 → 人 Review → 流水线打包

✓ 自动化测试（编译/单测/API/UI）
✓ CI/CD Pipeline
✓ 代码规范（lint/format）
✓ AI Code Review

Harness 五大子系统

✦ Feedback Loop
编译→单测→API→CI
✦ Memory Architecture
持久化上下文
✦ Tool Ecosystem
SKILL + MCP
✦ Spec Constraints
OpenSpec 需求管理
✦ Isolation
Git 分支/环境隔离

// three-primitives

Three Engineering Primitives

1. 隔离 Isolation

每个 Agent 有独立的工作空间。
Git submodule + 独立环境，
冲突在结构上不可能发生。

git worktree

2. 分解 Decomposition

Agent 不擅长"帮我搞这个模块"。
擅长的是：你给我边界，
给我验收标准。

OpenSpec / Ticket

3. 协调 Coordination

多 Agent 并行工作。
Supervisor 分配任务，
Worker 执行，Reviewer 审查。

tmux / Zellij

隔离是前提 → 分解是基础 → 协调是最后一环

// feedback-loop

多层反馈闭环

L1 LSP 语法检查 — IDE 实时语法、类型、导入错误
L2 编译构建 — Maven 编译、依赖解析、API 签名
L3 单元测试 — 逻辑回归、多租户隔离等边界条件
L4 API / 数据库 / UI 测试 — 多模块真实联动
L5 CI Pipeline — 全量测试/lint/构建，合并前的最后安全网

关键原则：反馈环路越短越精准，问题在第一层被拦住成本最低

// implementation · skill

SKILL = 自动化脚本，
让 AI 会用你的工具

SKILL 把运维经验封装成 AI 可调用的工具。

✦ ssh-skill — 远程服务器操作
✦ deploy-web-tomcat — 前端部署
✦ java-web-portal-unittest — 单元测试
✦ decrypt-service-code — 服务码解密
✦ openspec-* — 需求管理流程
✦ validator-* — 质量门禁

Codex 的 50+ SKILL

deploy-agent / frontend-deploy
apifox / eolink-api-harvest
git-branch / git-commit-standard
eslint / jest / vitest
github-actions / wait-ci
yunxiazi-db / server-log-viewer
pas-i18n / npm-to-pnpm
...

// implementation · openspec

OpenSpec：给 AI 看的规格说明书

核心原理：Delta 格式

OpenSpec 的核心创新是不重写完整规格，只记录变更的 diff。

## ADDED Requirements
The system SHALL support Google OAuth 2.0.
## MODIFIED Requirements
Sessions SHALL be persisted in Redis.
(Original: stored in memory.)
✓ 避免规格漂移（Spec Drift）
✓ 只记录变化，不重复存储历史

标准工作流

/opsx:propose "添加用户登录功能"
→ 一次性生成 proposal + design + specs + tasks
/opsx:explore 探索现有代码库
/opsx:apply 执行 tasks.md 清单
/opsx:archive 归档，合入主规格

规格必须包含

✓ 需求语言：SHALL / MUST 关键词
✓ 每个需求 ≥ 1 个具体测试场景
✓ 场景格式：Given / When / Then

一句话：把"模糊需求"变成"AI 能执行的精确规格"，从而让 AI 的输出可预期、可验证

// implementation · mcp

MCP 工具链集成：
AI 操控一切

已接入的服务（9个）

🔧 EOLINK — API 管理
🔧 Apifox — API Hub + CLI
🔧 Jenkins — 持续集成/部署
🔧 GitLab — 代码仓库
🔧 MySQL-prod — 生产数据库（只读）
🔧 Playwright — 浏览器自动化
🔧 chrome-devtools — 页面抓取/断言
🔧 wiki-qax — 内部知识库

MCP 的核心价值

AI 可以直接读生产数据、做 API 测试、执行部署——不需要人来回切换工具

协议层：Model Context Protocol
Anthropic 提出的工具调用标准

OpenSpec + MCP 组合

OpenSpec 定义做什么 → MCP 负责怎么做（执行工具操作）
两者结合：规格约束 + 工具执行 = 完整闭环

// implementation · multi-agent

三套 Agent 并行 +
AI Code Review

Claude Code

MiniMax 模型
Oh My ClaudeCode
20+ 专项 Agent

analyst / architect
code-reviewer / debugger
planner / executor

OpenCode

Qwen 模型
50+ SKILL
项目定制能力

deploy / git-branch
pas-i18n / eslint
openspec-*

Codex

GPT-5.4 模型
SuperPower 技能
全流程覆盖

brainstorming / writing-plans
subagent-driven-dev
TDD / code-review

AI Code Review 已实际运行：资源组模块 → 发现 4 个严重问题 + 3 个高/中问题
代码生成速度 >> 人 Review 速度 → 所以让 AI Review AI

// implementation · code-standards

代码规范 = AI 的工作手册

AGENTS.md 定义了团队约定，让 AI 知道什么该做、什么不该做。

✦ 中文注释，禁止行尾注释
✦ 禁止 Mock 代码
✦ NPE 防护：任何 get 都必须判空
✦ 禁止伪造实现（占位符/假数据）
✦ 修改完成后必须 mvn install

项目结构约定

📁 doc/ — 架构分析、设计文档
📁 doc/CodeReview/ — AI 审查报告
📁 doc/TestCase/ — 自动化测试
📁 credentials/ — 服务器凭据
📁 script/ — 运维脚本
📄 doc/spec/* — API/Task 开发规范

// tools landscape

CodingAgent 工具库大盘点
CodingAgent 工具

🌐 WEB 终端

· ClaudeCodeUI · Portal · Mobvibe
· vibetunnel · VibeGo · sled
· Farfield · Trellis · webcoding
· VibeAround · OpenCodeUI · hub-run
· opencode-vibe · opencode-studio

通过浏览器远程操控 Agent，适合手机/iPad 访问

🖥 本地工具

· VibeGo · ACP UI · AgentX
· AionUI · AgentDeck · CodePilot
· Aperant · codeg · CodeKanban
· EnsoAi · MossX · opskat
· superset · tamux · wmux

本地桌面应用，管理 Agent 会话和文件

📋 任务看板

· VibeKanban（Worktree 隔离）
· CodeKanban · Cline Kanban
· agent-orchestrator
· opencode-manager · agor
· automaker · multica

用看板组织多 Agent 任务，适合并行开发

🐾 OpenClaw 生态

· OpenChamber（进程守护+MCP）
· ClawX · ClawWork
· EasyClaw · lsbot
· hermes-agent

OpenClaw 官方/社区工具，主打多会话管理

🤖 IM Bot / 远程

· golembot（多 IM 接入）
· Vibe-Remote（Slack/Discord/微信/飞书）
· IM-Hub · cc-connect · tlive
· iLink（微信Bot）· opencode-remote-contro
· tgent · phoneshell

通过聊天软件远程操控 Agent，适合手机端

🧩 Agent 协作 / 框架

· openagents · claude_agent_teams_ui
· openteams · Aperant · multica
· Hephaestus（看板式多 Agent）
· OpenHarness

多 Agent 协作框架，适合团队作战

整理的 CodingAgent 工具库

这些工具本质上都是在利用 ClaudeCode、OpenCode 等 Coding Agent 的 CLI 能力，可用可不用，最简单的方法还是直接使用 CLI

// results

实际效果：资源组模块

之前（纯人工）

需求分析 + 设计 + 开发 + 单测 + API 测试 + 部署预估：12 人天

现在（AI 辅助）

AI 生成 + Harness 兜底 + 人 Review
预估：4 人天

AI 实际产出的内容

✅ 概要设计文档（SDD）
✅ 资源组 CRUD API 测试（13/16 通过）
✅ 权限 API 测试（18/21 通过）
✅ 数据库一致性验证（结构/外键/索引）
✅ 前端 UI 自动化测试（截图验证）
✅ AI Code Review 报告（7个问题分级）
✅ SQL 升级脚本验证

// gaps

全流程还差什么

✅ 已落地

✓ 编译检查（Maven）
✓ 单元测试（JUnit）
✓ API 自动化测试（Python）
✓ 数据库验证
✓ 前端 UI 测试（Playwright MCP）
✓ AI Code Review
✓ MCP 工具链（Jenkins/GitLab/DB）

🔧 已积累的 MCP

chrome-devtools · playwright · wiki-qax · mysql-prod
APIPark · Scalar · apifox（读文档/CLI）
web-mcp（浏览断言/API 调试）

🛠 已积累的 SKILL

概要设计文档 · git-commit规范 · SSH操作
Java 打包部署 · 更新包生成 · 单测执行
UI 打包部署 · Tomcat日志 · 国际化文本
数据库操作脚本 · patch脚本
opencode · claude code · codex 协作脚本

⏳ 未完成 / 进行中

○ e2e 端到端测试（文档有，落地中）
○ CI Pipeline 自动串联
○ AI Review → 自动修复反馈闭环
○ 部署后自动验证
○ 多 Agent 自主协作（Supervisor 模式）

// lessons-learned

踩坑经验：
这些方案我们试过，不 work

❌ Vibekanban

用任务的方式组织 Agent

✕ 单需求开发 — 不需要

单一开发需求上，Vibekanban 的任务拆分反而是负担。Agent 本身就擅长处理模糊任务，不需要人先拆好。

✕ 多任务并行 — 人的负担太大

多个 Agent 同时跑，人需要同时检查多个 Agent 的执行结果，变成了人在"监工"而不是人在"审核"。

结论：人同时盯多个 Agent → 瓶颈在人，不是 AI

❌ Openclaw + Tmux

用 Tmux 监工 Claude Code 等 Agent

✕ 人无法真正脱手

Agent 执行过程中遇到问题，仍需要人介入决策。Tmux 监工变成了"人在旁边等着"，并没有真正释放人的时间。

✕ 上限太低

Openclaw + Tmux 的组合适合个人开发者小规模使用，扩展到团队多人协作时，沟通成本骤增。

结论：人的介入点必须前移，在规格层约束 AI，而不是在执行层救火

核心教训：工具是为工作流服务的，不要为了用工具而用工具

// limitations

局限性：
Human in the Loop 是必须的

AI 代码生成速度 >> 人 Review 速度。
所以业界有了 AI Review AI。

以前：人写代码 → 人 Review → 人 merge
现在：AI 写代码 → 人审核 AI Review → 循环反馈给 AI 修复 → 人 merge
但全流程跑下来，人依然在流程里——
只是在更关键的位置。

人无法被替代的地方

🔴 业务判断 — 需求对不对、合不合理
🔴 架构决策 — 模块怎么拆、依赖怎么理
🔴 安全红线 — 权限/数据/合规问题
🔴 代码质量 — 常用方法、最优实现、可维护性
🔴 最终拍板 — merge 权限在人手里

结论

AI 是工具，不是大脑。
Harness 是让 AI 靠谱 的工程手段，
不是让 AI 自主 的自动驾驶。

// summary

总结

1 Harness Engineering = 软件工程全流程自动化，不是什么新技术名词
2 PAS AI 全栈 = SKILL（工具）+ OpenSpec（分解）+ MCP（集成）+ 四层反馈（质量）+ 规范（约束）
3 全流程还没走完 — e2e、CI 自动串联、部署后验证是下一步
4 Human in the Loop 必须存在 — AI 生成 + AI Review + 人 merge，在瓶颈处用 AI 增强人

Q&A

欢迎提问，一起探讨 AI 辅助开发的实践