正儿八经 - 资深技术专家

上一篇《从一次 tenantId 联调 bug，看我们该怎么给 AI 项目补齐 harness》里，我记录了一个真实项目中的 harness 搭建过程。

那次经历让我意识到：

AI 工程化的竞争力，不是”谁的模型更像天才”，而是”谁先把自己的真实环境整理成一个不会误导 agent 的工作台”。

但「补齐 harness」这件事，说起来容易，做起来却有很多模糊地带——

• Harness 到底包括哪些具体的东西？
• 什么场景下应该优先补哪部分？
• 业界那些号称”零手写代码”的项目，他们的 harness 是怎么设计的？

这篇不聊具体 bug 了，我想从概念、分类、工程实践三个层面，把 Harness 这件事系统地理清楚。

如果你也在搞 AI Coding，正在困惑”除了写 prompt 还应该做什么”，这篇应该能帮到你。

[^1]: Harness engineering: leveraging Codex in an agent-first world - OpenAI, 2026-02-11

什么是 Harness？

Harness = 用来控制、驱动、约束、评估一个系统行为的外部执行框架

换句话说：

• ❌ 不是业务逻辑
• ✅ 是”包在系统外面的一层控制系统”

类比理解

核心本质：让一个”有能力但不可控”的系统变得可控。[^2]

[^2]: Test harness - Wikipedia

传统软件中的 Harness（你其实一直在用）

在 AI 火爆之前，Harness 这个概念已经在软件工程中存在几十年了。你可能每天都在用，只是没意识到。

1. Test Harness（测试框架）——最经典

这是 Harness 一词在软件工程中最常见的用法。

1
2
3
4
5
6
7
8
9

被测系统（SUT） ←→ Test Harness
                ↑
        ┌───────┴───────┐
        │  - 输入构造    │
        │  - Mock/Stub   │
        │  - 执行控制    │
        │  - 输出验证    │
        │  - 日志收集    │
        └───────────────┘

实际例子：

• JUnit / TestNG 测试框架
• 集成测试时启动的嵌入式数据库（H2）
• 模拟外部 API 的 WireMock / MockServer

2. Benchmark Harness（基准测试框架）

Java 开发者最熟悉的 JMH（Java Microbenchmark Harness）就是典型代表。[^3]

[^3]: JMH - OpenJDK

1
2
3
4
5
6
7
8

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class MyBenchmark {
    @Benchmark
    public void testMethod() {
        // 被测代码
    }
}

Harness 的作用：

• 预热 JVM，消除 JIT 编译影响
• 多轮运行，统计置信区间
• 控制 GC 时机，减少干扰
• 输出标准化的性能报告

3. Integration Harness（集成测试框架）

日常开发中常用的：

1
2
3
4
5
6
7
8
9
10
11
12

# docker-compose.test.yml
version: '3'
services:
  app:
    build: .
    depends_on:
      - postgres
      - redis
  postgres:
    image: postgres:15
  redis:
    image: redis:7

这就是一种 Harness——构造一个可控的系统环境。

其他例子：

• 流量回放工具（GoReplay、TCPReplay）
• 混沌工程工具（Chaos Monkey）
• 负载测试工具（JMeter、k6）

4. 安全 Harness

• 沙箱（Sandbox）：限制程序能访问的资源
• Seccomp：Linux 系统调用过滤
• 浏览器沙箱：Chrome 的多进程架构

这些都是 Harness 的变体：给”有能力但不可控”的系统加上约束。

说明：上文采取的是”广义 harness”用法，用来帮助理解”外层控制框架”这一共同本质；在不同子领域里，具体术语并不完全相同（如 sandbox/seccomp 更常见的分类是 security isolation，test harness 是软件工程的固定用法，而 agentic coding 语境下的 harness 更接近 orchestration + context + tools + validation + feedback loops）。

2025 年底到 2026 年初：长时自主 Agent 的工程实践升温

到 2025 年底到 2026 年初，行业里关于长时自主 agent 的工程实践明显升温，多个团队开始公开分享长时任务、多 agent 协作、可读环境与 harness 设计经验。

从”人类驱动”到”长时自主”

之前的 AI 工具（包括 ChatGPT、Copilot）大多是人类驱动的——你需要不断提示下一步动作。

但 2026 年的新趋势是长时自主智能体（long-running autonomous agents）：

• OpenClaw：通过内存上下文 + 触发器 + Cron 任务，实现持续自主运行
• Cursor：报告了一个”构建浏览器”的长时自主编码实验，官方写法是 over 1 million lines of code；他们同时还展示了其他长期并发 agent 项目
• Anthropic：用并行 Claude agents 构建了一个 Rust 写的 C compiler，重点不是”炫技”，而是总结如何为长时自主 agent team 设计 harness

这些项目的共同点是：AI 不再等待人类指令，而是自主规划和执行长时任务。

新问题出现了

当 AI 可以连续运行数小时甚至数天时，Prompt Engineering 和 Context Engineering 都不够了：

• 如何确保跨会话的上下文连贯？
• 如何让下一个”接手”的 Agent 快速理解当前项目状态？
• 如何验证 Agent 的产出是否正确（而不是让它自己说”完成了”）？
• 如何设计工具和环境，让模型表现最佳？

这就是 Harness Engineering 要解决的问题。

为什么 AI 时代 Harness 突然重要？

因为 LLM = 非确定性系统（Non-deterministic system）

传统软件 vs AI 系统

同一个 Prompt：

• 第一次正确
• 第二次错误
• 第三次又正确

这就是 AI 开发的日常。

从 Prompt Engineering 到 Harness Engineering

阶段一：Prompt Engineering（2023-2024）

关注点是”我怎么写 prompt 更聪明”。

1

给定角色 + 分步骤 + 加示例 → 期望输出

阶段二：Context Engineering（2025）

Andrej Karpathy 在 2025 年的推文中强调：**”context engineering > prompt engineering”**。[^4]

关注点是”模型在推理时能看到什么完整上下文”。

1

RAG + MCP + Memory + 外部工具 → 丰富上下文

[^4]: Andrej Karpathy on X - 2025

阶段三：Harness Engineering（2026-）

当 AI 智能体开始执行长时自主任务（long-running autonomous tasks），Context Engineering 也不够用了。

Harness Engineering 的核心关注点：

1. 跨会话设计 —— 任务可能持续数小时、数天，需要中断和恢复
2. 多智能体协作 —— 不同 Agent 如何接力完成任务
3. 上下文检索 —— 每个新会话如何快速获取相关上下文
4. 工具设计 —— 选择什么样的工具让模型表现最佳
5. 验证机制 —— Agent 会过早声明”完成”，需要独立验证

智能体的常见问题：

• 忽略团队规范
• 生成违反架构依赖方向的代码
• 在并行执行时相互冲突
• 通过”熵增”逐渐降低代码质量
• 过早声明任务完成（而实际上有 bug）

这些问题不是”模型应该看到什么”，而是：

“系统应该阻止什么、测量什么、修复什么、验证什么”

2026 年 2 月，HashiCorp 联合创始人 Mitchell Hashimoto 在博客中明确使用了 “harness engineering” 这一说法，并赋予了它清晰的工程含义：”I don’t know if there is a broad industry-accepted term for this yet, but I’ve grown to calling this ‘harness engineering.’” [^5]

[^5]: Mitchell Hashimoto - My AI Adoption Journey - 2026-02

AI Harness 的核心定义

AI Harness = 用于系统性验证、评估、对比、约束 LLM 行为的工程基础设施

架构组成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

┌──────────────────────┐
│     Test Dataset     │  ← 测试数据集（Prompt + Context）
│ (Prompt + Context)   │
└─────────┬────────────┘
          ↓
┌──────────────────────┐
│      Harness         │  ← 执行框架
│                      │
│ - 调用模型           │
│ - 控制参数           │
│ - 重试策略           │
│ - 日志记录           │
└─────────┬────────────┘
          ↓
┌──────────────────────┐
│     Evaluator        │  ← 评估器（规则 / LLM评估）
│ (规则 / LLM评估)     │
└─────────┬────────────┘
          ↓
┌──────────────────────┐
│      Metrics         │  ← 指标（准确率 / 稳定性 / 延迟）
│ (accuracy / score)   │
└──────────────────────┘

真实案例：没有 Harness vs 有 Harness

场景：客户对话意图识别

输入：客户说”这个太贵了”
期望输出：{"intent": "价格异议"}

❌ 没有 Harness

• 手动调 Prompt
• 靠感觉判断效果
• 不可复现

👉 玄学开发

✅ 有 Harness

Step 1：构建测试集

1
2
3
4
5
6
7
8
9
10
11
12

[
  {
    "id": "case_001",
    "input": "客户说：这个太贵了",
    "expected": {"intent": "价格异议"}
  },
  {
    "id": "case_002", 
    "input": "能便宜点吗",
    "expected": {"intent": "价格异议"}
  }
]

Step 2：执行 Harness

• 调用 LLM
• 控制 temperature
• 多次运行取平均

Step 3：评估

1
2
3
4
5
6
7
8
9
10
11

# 规则评估
assert actual.intent == expected.intent

# 或用 LLM 评估（LLM-as-a-Judge）
judge_prompt = f"""
评估以下输出是否正确：
输入：{input}
期望：{expected}
实际：{actual}
返回：正确/错误 + 原因
"""

Step 4：输出指标

1
2
3

accuracy = 87%
stability = 方差 < 5%
avg_latency = 450ms

👉 本质：把 AI 从”感觉好不好”变成”指标好不好”[^6]

[^6]: LLM Testing Framework Guide - Leanware, 2025-11-13

OpenAI 的实验数据

OpenAI 在 2025 年 8 月-2026 年 1 月进行了一项实验：[^1]

关键点：初期生产力很低，因为环境、工具、抽象和 repo 内部结构尚未充分为 agent 优化。随着 Harness 逐步完善，性能才大幅提升。

工程师的角色变成了”让智能体有用”——设计系统、架构和约束条件。

Harness 改变结果的惊人案例

案例 1：Hashline（Can Boluk, 2026）

安全研究员 Can Boluk 发布了一个实验，只改变智能体的编辑格式：[^5]

1
2
3
4
5
6
7
8
9

# 传统格式
function hello() {
  return "world";
}

# Hashline 格式（每行加 2-3 字符哈希）
1:a3|function hello() {
2:f1|  return "world";
3:0e|}

智能体可以通过哈希引用行（如”替换 2:f1”），而不需要精确重现字符串。

结果：

• Grok Code Fast 1 的基准测试分数从 6.7% → 68.3%
• 平均输出 token 减少约 20%
• 模型权重没变，只有 Harness 变了

案例 2：LangChain（Terminal Bench 2.0）

固定使用 gpt-5.2-codex 模型，只改进 Harness：[^5]

• 分数从 52.8% → 66.5%（+13.7 分）
• 排行榜排名从约 30 名 → 约 5 名

主要改进是添加了一个自动分析失败模式的工具。

结论：在换模型之前，先检查 Harness。它往往提供最高的 ROI。

AI Harness 的核心组件

基于 OpenAI、Anthropic、Vercel 等公司的实践，一个完整的 AI Harness 应该包含：[^7][^8]

[^7]: How to Evaluate LLMs on Your Own Data - AI Engineer Lab, 2026-03-13
[^8]: LLM Evaluation Framework - Zep AI, 2025-03-01
[^11]: Anthropic - Building a C compiler with a team of parallel Claudes
[^12]: Vercel - We removed 80% of our agent’s tools

0. 可读环境（Legible Environment）—— 长时任务的基础

对于长时运行的智能体，最重要但最容易被忽视的是环境可读性。

当一个新的 Agent 会话”接手”任务时，它需要在几分钟内理解：

• 项目当前状态是什么？
• 已经完成了什么？
• 下一步要做什么？

最佳实践：

关键原则：

每个会话应该能快速”读懂”项目，而不是靠猜测或试错。

Vercel 和 Anthropic 的实践表明：结构化的进度跟踪文件比复杂的记忆系统更有效。[^11]

1. Test Case 管理

1
2
3
4
5
6
7
8
9
10

{
  "id": "case_001",
  "input": "...",
  "expected": {...},
  "metadata": {
    "category": "价格异议",
    "difficulty": "medium",
    "source": "production_log"
  }
}

2. 执行器（Executor）

• 支持多模型（GPT / Claude / DeepSeek / Qwen）
• 支持多 Prompt 版本
• 控制温度、重试策略

3. Evaluator（评估器）

4. Metrics（指标）

• accuracy：意图识别准确率
• faithfulness：事实一致性（防幻觉）
• stability：多次运行方差
• latency：响应延迟
• cost：单次调用成本
• format_reliability：结构化输出成功率

5. E2E 验证（端到端测试）—— 防止”假完成”

关键洞察：Agent 有强烈的倾向过早声明任务”完成”。这一观察来自多个团队的自主 agent 实验总结。

单元测试不够，因为 Agent 可能：

• 代码通过了测试，但功能不工作
• 实现了功能，但引入了回归 bug
• 完成了任务，但破坏了其他模块

解决方案：提供端到端验证工具

反馈循环：

1

Agent 声明完成 → E2E 测试 → 失败 → 反馈给 Agent → 修复 → 重新验证

这比人工检查快得多，也更可靠。

6. 工具设计：通用优于专用

Vercel 的实践经验：[^12]

• 原来：大量 specialized tools
• 改进后：删掉大部分工具，只保留非常少的基础工具，核心是一个 execute arbitrary bash commands 的 file system agent，再加 ExecuteSQL

结果（在 5 个代表性查询上）：

• 成功率：从 80% → 100%
• 速度：从 274.8s → 77.4s，快 3.5 倍

原因：

• 模型对通用原生工具（如 bash）的理解更深刻
• 减少工具选择的开销
• 批处理减少往返次数

设计原则：

让模型直接面对 legible file system + 少量通用工具，而不是复杂的专用工具链。

7. CI/CD 集成

1
2
3

git push →
自动跑 harness →
指标下降 → 阻断发布

[^9]: DeepEval - LLM Evaluation Framework

可用的 Harness 工具生态

开源框架

商业平台

工程落地建议

起步三要素

1. 写上下文文件

   创建 CLAUDE.md 或 AGENTS.md，包含：

   • 项目结构
   • 构建命令
   • 编码规范

   每次智能体犯错，就添加一条防止再犯的规则。[^5]

2. 选择性地连接 MCP

   如果智能体经常引用某个外部系统，就通过 MCP 连接它。典型例子包括 Issue Tracker、Wiki、监控系统。

   但只连接必要的，否则 token 会被浪费。

3. 从简单评估开始

   • 收集 50 个真实生产 Prompt
   • 在 3-5 个模型上运行
   • 人工评分，对比差异
   • 逐步自动化

常见陷阱

核心总结

Harness 的本质：让不可控系统变成可度量、可优化、可上线的工程系统

AI 开发的核心资产正在转移：

如果用传统软件工程类比，Harness Engineering 有点像 JUnit、CI/CD、测试基建、脚手架、约束机制和运行环境设计的组合体——它覆盖的不只是”评测和 CI”，还包括 agent legibility、repo as system of record、AGENTS.md、自动化反馈循环、工具约束、任务接力、E2E verification、并行协作结构。

你写的 Prompt、RAG 流程、Agent 逻辑——这些都需要被评估、被约束、被持续监控。

参考资源

官方/论文

• OpenAI Harness Engineering - OpenAI 官方文章
• OpenAI Evals - 官方评估框架
• HELM - Stanford - 全面的 LLM 评估基准
• Test Harness - Wikipedia

工程实践

• Promptfoo - 开源 Prompt 测试框架
• DeepEval - Python LLM 评估框架
• LangChain Evaluation - LangChain 评估指南

深度解读

• Beyond Prompts and Context: Harness Engineering - 概念演进时间线
• OpenAI Harness Engineering - InfoQ - 中文技术解读
• LLM Testing Framework Guide - 测试框架最佳实践
• How to Evaluate LLMs - 实用评估方法

官方工程博客

• OpenAI - Harness engineering - OpenAI 官方 Harness Engineering 文章
• Anthropic - Building a C compiler with parallel Claudes - Anthropic 并行 agent 实验
• Cursor - Scaling long-running autonomous coding - Cursor 长时自主编码实验
• Vercel - We removed 80% of our agent’s tools - Vercel 工具设计经验
• Mitchell Hashimoto - My AI Adoption Journey - Harness Engineering 概念提出

视频

• Andrej Karpathy - Software 2.0 - 关于 AI 软件范式的经典演讲

最后

我们正处在一个转折点。

Prompt Engineering 只是开始，Context Engineering 是中间阶段，而 Harness Engineering 是 AI 应用走向生产就绪的必经之路。

如果你正在开发 AI 应用，不妨从今天开始：

1. 收集 50 个真实的测试用例
2. 建立一个简单的评估脚本
3. 在每次 Prompt 变更时跑一遍

这就是 Harness 的起点。

前几天在 X 上看到一篇关于 Claude Code Skills 的深度分享，作者是 Anthropic 的 Thariq。文章总结了他们团队内部数百个 Skills 的实战经验，信息量很大，读完收获颇多。

原文链接：https://x.com/trq212/status/2033949937936085378

今天整理一下核心观点，顺便加上自己的一些思考。

一个常见误解

很多人以为 Skills “就是个 Markdown 文件”，放几句提示词而已。

实际上，Skills 是一个完整的文件夹，可以包含脚本、数据、模板等资源。Claude Code 会在合适的时候读取这些内容，就像给一个专家配备了全套工具箱。

这个区别很重要——它决定了你是做一个”简单的提示词模板”，还是做一个”真正能解决问题的智能助手”。

Skills 的九种类型

Thariq 把 Anthropic 内部的 Skills 分了九大类。这个分类很有参考价值，可以对照看看自己的技能库缺了哪一类：

1. 库与 API 参考

解释如何正确使用某个库、CLI 或 SDK。重点是记录边缘案例和常见陷阱，而不是重复文档。

例子：

• 内部计费库的 edge cases
• 出口网关的配置和调试方法
• 某个 SDK 的版本差异

2. 产品验证

描述如何测试代码是否正常工作，常搭配外部工具。

例子：

• 用 Playwright 跑完整注册流程
• 用 Stripe 测试卡验证结账流程
• 需要 TTY 的交互式 CLI 测试

这类 Skills 特别值得投入时间打磨，因为能保证 AI 输出的正确性。

3. 数据获取与分析

连接数据系统和监控平台，包含查询规范、仪表板 ID、常见工作流。

例子：

• 用户留存率查询
• Grafana/Datadog 数据源配置
• 转化率对比分析

4. 业务流程与团队自动化

把重复工作流压缩为一条命令。

例子：

• 聚合 Ticket、GitHub、Slack 生成站会报告
• 自动格式化周报
• 标准化 Ticket 创建流程

5. 代码脚手架与模板

为特定功能生成框架代码。

例子：

• 新建内部应用（预配置认证、日志、部署）
• 迁移文件模板 + 常见陷阱
• 新建服务/工作流的标准结构

6. 代码质量与评审

强制代码质量，帮助代码评审。

例子：

• 生成”新鲜视角”子 Agent 进行批判性评审
• 强制特定代码风格
• 测试编写指南

7. CI/CD 与部署

帮助获取、推送、部署代码。

例子：

• 监控 PR → 重试 flaky CI → 解决冲突 → 自动合并
• 渐进式部署 + 错误率监控 → 自动回滚
• Cherry-pick 到生产环境的标准流程

8. 运行手册 (Runbooks)

输入症状，输出结构化诊断报告。

例子：

• 某服务的调试手册（症状 → 工具 → 查询映射）
• On-call 告警自动排查
• 根据 request ID 关联所有相关日志

9. 基础设施运维

执行日常维护与操作（含破坏性操作，需要防护栏）。

例子：

• 发现孤儿资源 → 通知 → 浸泡期 → 用户确认 → 清理
• 依赖审批工作流
• 成本异常调查

制作 Skills 的实用技巧

1. 不要陈述显而易见的内容

Claude 已经知道很多东西。Skills 应该聚焦在”让 Claude 跳出常规思维”的信息上。

例子：前端设计 Skill 通过与用户迭代，避免 Inter 字体和紫色渐变等”AI 味”设计。

2. 建立 Gotchas 专区（最有价值的内容）

记录 Claude 使用这个 Skill 时常见的失败点，持续更新。

真实例子：

• “subscriptions 表是 append-only，取最高 version 而非最新 created_at”
• “API gateway 用 @request_id，billing service 用 trace_id，但值相同”
• “Staging 返回 200 但 Stripe webhook 未处理，需查 payment_events”

3. 利用文件系统做渐进式披露

Skill 是文件夹，可以把详细内容拆分到不同文件：

• references/api.md - 详细 API 签名
• assets/ - 模板文件供复制
• scripts/ - 现成脚本

让 Claude 知道文件夹内容，它会在需要时读取。

4. 避免过度约束

Skill 要可复用，指令不要过于死板。提供必要信息，保留适应性。

5. 提前考虑配置

部分 Skill 需要用户上下文（如 Slack 频道）。建议用 config.json 存储配置，未配置时让 Agent 询问用户。

6. 内存与数据存储

Skill 内可以实现”内存”：追加日志、JSON 或 SQLite。建议存入稳定路径（如 ~/.claude），避免 Skill 升级时丢失数据。

例子：standup-post 保留 standups.log，下次运行时自动对比昨日变化。

7. 存储脚本 + 生成代码

给 Claude 现成脚本/库，让它专注组合而非重写样板。

8. 按需 Hooks

仅在调用 Skill 时激活的临时 Hooks。

例子：

• /careful：仅在生产环境阻挡危险命令
• /freeze：锁定仅允许特定目录的编辑

分发与管理

小规模：检入仓库

直接放在 ./.claude/skills，适合小团队。

大规模：制作 Plugin

通过 Claude Code Plugin 市场分发，避免每个 Skill 都增加上下文负担。

管理市场的经验

• 无中心化审核团队
• 开发者先上传到 sandbox 文件夹，在内部渠道推广
• 获得 traction 后提 PR 进入市场

组合 Skills

直接通过名称引用其他 Skills，模型会自动调用（前提是已安装）。

衡量使用情况

使用 PreToolUse Hook 记录 Skill 使用日志，可以发现哪些是热门 Skill，哪些没人用。

我的几点思考

1. Skills 的本质是”可复用的上下文”

以前用 Claude，每次都要在对话里交代一堆背景信息。Skills 把这些背景”固化”下来，变成可复用的资产。

这和编程里的”抽象”是一个道理——把通用的东西抽出来，下次直接用。

2. Gotchas 比 Reference 更有价值

文档能告诉 Claude “API 怎么用”，但只有实战经验能告诉它 “这里容易踩坑”。

这也是人类工程师的价值所在——不是记得住多少文档，而是知道哪些地方容易出问题。

3. 从”用完即走”到”持续积累”

Thariq 提到他们大多数 Skills 最初只是几行文字 + 一个 gotcha，后来因 Claude 不断碰到新边缘案例而持续完善。

这和我们写代码一样——先跑起来，再迭代优化。不要想着一次做到完美。

4. 对国内用户的现实考量

Claude Code 在国内的使用还有一些门槛（网络、账号、价格）。但这些方法论是通用的：

• 如果你用 Cursor/Windsurf，可以借鉴这个分类思路整理 .cursorrules
• 如果你用其他 AI 工具，也可以建立自己的”提示词库”

核心是：有意识地积累和复用上下文，而不是每次都从零开始。

结语

Skills 还处于早期阶段，大家都在摸索最佳用法。这篇分享更像是一个”有用技巧合集”，而非权威指南。

最好的学习方式就是动手实验，不断迭代。

如果你已经在用 Claude Code，不妨从整理一个最常用的工作流开始，把它做成 Skill。你会发现，AI 助手越用越顺手。

参考链接：

• 原文推文 - @trq212
• Skilljar 课程 - 《Agent Skills》入门课程
• Claude Code 文档

最近输出有点频繁，主要是这几天项目没那么满，再加上龙虾每天都在逼我成长，老跟我聊各种话题。

今天刚好聊到一个很典型的管理问题：老板觉得工期慢，或者会追着问一句“这个时间还能不能再快点？”后来回头看，这事儿还真不是一个维度能说清的。

这事我是真踩过坑。

前阵子带团队做项目，老板很着急，想尽快把产品推出来。这个诉求本身没毛病，谁做项目不想快一点呢。

问题是，每次汇报进度，他都觉得还是慢，或者会继续追问一句：

“这个时间有没有办法再压一压？”

这句话听起来很普通，但真落到团队身上，杀伤力其实不小。

因为它后面往往会带出一连串动作：要不要加人，要不要并行，要不要砍流程，要不要先糙一点上线。

我后来回头看，问题根本不是一句“人不够”能解释的，甚至很多时候，核心矛盾都不是“要不要加人”。

真正的问题是：老板觉得慢，到底是真的慢，还是大家看问题的角度不一样？

如果硬套芒格那句老话，就是：别一上来就拿一个动作当答案。

单一思维最容易把人带沟里

工程师和老板在这件事上，其实都很容易掉进同一个坑：

• 进度慢
• 开始着急
• 立刻想办法压工期
• 先上动作，再看问题

逻辑听起来很顺，但现实里经常不成立。

因为软件研发不是搬砖。你以为自己在压时间，实际可能只是把复杂度、返工和沟通成本往后推。

所以这类问题，如果只用一个视角看，很容易越搞越乱。你得换几个角度一起看，才比较接近真相。

下面这几个角度，是我后来觉得最有用的。

五个视角，拆开看这件事

1. 心理学：损失厌恶——团队不一定是不会干，可能是不敢快

很多团队进度慢，不是因为能力差，而是因为大家怕出错。

一旦环境里“延期要挨骂”“出问题要背锅”这种信号太强，团队就会本能地保守。估时往大了估，执行往后拖，很多人宁愿慢一点，也不想冒风险。

这时候表面上看像是效率低，实际上是恐惧驱动出来的低效。

这种场景下，你跟老板如果只说“时间不够”，他通常听不进去。更有用的话术反而是：

“我观察下来，团队最近估时都比较保守，执行也容易拖到后面。不是大家不想快，更像是怕出问题。要不要先看看是不是当前沟通方式让大家太怕犯错了？”

这个说法的关键，不是替团队喊冤，而是把“慢”从能力问题，拉回到环境问题。

2. 经济学：边际效用递减——你想压工期，先算算代价

很多人一听“能不能更快”，第一反应就是加动作。

比如：

• 多上几个人
• 并行做更多事
• 少做一些校验
• 先把过程压扁

但经济学里有个很朴素的点，叫代价。

任何“更快”都不是白来的，你这边省下来的时间，往往会在另一边以返工、沟通、质量风险的形式补回来。

其中最典型的，就是中途加人。团队从 3 个人变成 5 个人，看上去只多了 2 个人，但沟通路径会从 3 条变成 10 条。再加上新人熟悉业务和上下文，短期内未必真能把工期压下来。

所以这时候你跟老板沟通，不要只说“压不了”，而是把代价说清楚：

“如果要继续压时间，不是不行，但代价得一起看。比如中途补人，短期内协作成本会明显上升；如果砍流程，后面返工和质量风险也会跟着上来。”

这类话比“我们已经很努力了”更有效，因为它是在聊投入产出。

3. 系统论：瓶颈理论——老板看到的是工期，项目卡住的可能是别的地方

这是我后面越来越信的一件事。

很多项目看起来卡在开发，实际上真正堵住节奏的，压根不是开发。

常见的瓶颈可能是：

• 需求反复改
• 产品决策慢
• 测试环境不稳定
• 关键人拍板不及时
• 上下游依赖一直等

如果真正卡住项目的是这些地方，那你就算拼命压开发时间，也不一定有用。

就像高速收费站堵了，你在后面再多放几辆车，意义并不大。

我后来比较常用的做法，是先把时间花在哪儿拆出来。比如开发占多少、等确认占多少、返工占多少、等环境占多少。只要这个账一拉，很多争论就会自动消失。

因为当你能明确说出：

“开发只占整个周期的 30%，等决策和返工占了大头。”

那老板自然就会明白，问题不在“开发还不够快”。

4. 概率论：规划谬误——不是大家故意乐观，是人天生就会低估难度

项目管理里有个很烦但很真实的事：大家总会低估复杂度。

估计划的时候，脑子里默认都是理想状态：

• 需求差不多稳定
• 没有特别难的坑
• 联调不会出问题
• 关键人能及时回复

但真实项目哪有这么顺。

所以很多“老板觉得慢”的背后，其实不是团队真慢，而是最开始那个预期本来就立得太乐观。

这时候最有用的不是争辩，而是把历史数据翻出来。

比如你可以这么聊：

“同规模的需求我们过去做过 4 次，平均耗时是 3.5 周，最短也接近 3 周。现在按 2 周来压，风险会很高。”

一旦把“我感觉”换成“历史上就是这样”，沟通就会轻松很多。

老板不一定认同你，但他很难无视数据。

5. 决策理论：选项设计——别只回一句”压不了”，给他选项

这是我自己吃过亏之后改得最明显的一点。

以前老板一问“还能不能更快”，我第一反应就是解释为什么快不了。后来发现这种沟通方式很被动，因为你只有一个姿态：否定。

否定久了，对方很容易觉得你是在挡事。

更好的办法，是别只给结论，给方案。

比如直接摆三个选项：

方案 A：继续压工期，比如补人或者并行赶工，短期看上去积极，但协作成本和质量风险都会上来。

方案 B：先切核心功能上线，剩余部分下一轮补，整体节奏更稳。

方案 C：不继续压时间，接受延期一周，把质量保住。

这时候你不是在和老板对抗，而是在帮他做决策。

很多管理沟通，关键不在于“你说得对不对”，而在于“你有没有把选择面铺开”。

我后来是怎么处理这类问题的

后面再碰到类似场景，我基本会先做三件事。

1. 先找真实瓶颈

别急着下结论，先看时间到底耗在哪儿。

开发慢，只是结果。真正的原因，可能是确认慢、返工多、依赖卡住，甚至是汇报链路太长。

2. 汇报时别只报进度，要报权衡

我后来比较喜欢把方案讲成“快、稳、折中”三个版本。

• 快：能更早上线，但要接受技术债和返工风险
• 稳：周期更长，但质量更可控
• 折中：先上核心，剩下分批补

这样老板听到的就不只是“你们做不完”，而是“不同选择分别意味着什么”。

3. 核心团队尽量小

很多事情不是人越多越好，尤其是前期探索阶段。

团队小一点，沟通短一点，边界清一点，节奏通常反而更快。真要补人，也尽量补在外围，不要一股脑全塞进核心链路里。

一个很实用的自检框架

下次老板再说“这个时间还能不能再快点”，你可以先在脑子里过一遍这五个问题：

有时候你把这五个问题想清楚，答案基本就出来了。

写在最后

我现在越来越觉得，管理里很多“看起来很简单”的问题，其实都不能只拿一个招去解。

老板觉得慢，未必是真的慢。

他说“能不能再快点”，很多时候也不是在指挥具体动作，而是在表达压力、目标和预期。

而我们如果只会回一句“快不了”，那本质上也没有把问题讲清楚。

多元思维模型对我最大的价值，不是让我显得懂很多学科，而是提醒我：

先把问题看准，再决定用什么办法。

不然的话，压工期、加人、砍流程，最后都可能只是看起来很努力。

你最近如果也碰到类似的问题，不妨别急着给动作，先换两个角度看看。

很多时候，真正该先补的不是人，而是对问题的判断。

参考资料

• 《穷查理宝典》（Poor Charlie’s Almanack） - 彼得·考夫曼（Peter D. Kaufman）编，2005 年
• 查理·芒格 1994 年南加州大学商学院演讲 - 《论基本普世智慧及其与投资与商业的关系》
• 《人月神话》（The Mythical Man-Month） - 弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）著，1975 年
• 《目标》（The Goal） - 埃利亚胡·高德拉特（Eliyahu M. Goldratt）著，1984 年
• 丹尼尔·卡尼曼（Daniel Kahneman） - 损失厌恶（Loss Aversion） 理论

前几天我读了 OpenAI 那篇文章：Harness engineering: leveraging Codex in an agent-first world。

我读完最大的感受不是“AI 又强了”，而是另一个更接地气的结论：

很多时候，不是模型不够强，而是你的工程环境没有把“正确性”暴露给模型。

这两天我正好在自己项目里处理一个非常典型的问题：运营端新增门店和校验门店名时，如果和其它租户重名会误报；员工后台接口也有类似的租户范围问题。表面上看只是个 tenantId bug，但整个过程把一个事实暴露得很彻底：

AI 想高效干活，前提不是 prompt 更长，而是 harness 更清楚。

一、这次 bug 表面是租户问题，实质是“环境表达不清”

最初的现象其实很迷惑：

1. 运营端调用 admin/store/checkName
2. 明明传了 tenantId
3. 但接口判重却像是按别的租户在查

如果只看 Controller 参数，你会以为“不是都传进来了吗”。
但真正往下追，就会发现系统里其实混着两套租户来源：

• 请求里显式传入的 tenantId
• 线程上下文里的 TenantContextHolder

理论上，TenantContextHolder 也不是错的。因为网关或 filter 确实会从 header 里解析租户并写入上下文。问题在于：

后台管理接口的业务语义，不是‘当前会话属于哪个租户’，而是‘当前运营账号要操作哪个目标租户的数据’。

这两个概念，在多租户后台系统里根本不是一回事。

所以这次真正的问题不是一句“代码写错了”，而是：
系统没有把“哪一个租户才是业务真相”表达得足够显式。

这就是 harness 问题。

二、OpenAI 那篇文章对我最有启发的，不是模型能力，而是“把环境当产品做”

那篇文章里有几层意思我特别认同，我这里不逐字复述，只说我自己的理解。

1）Agent 的上限，很大程度取决于它能不能直接看到真实运行环境

如果模型只能读代码，看不到：

• 实际 HTTP 请求长什么样
• token 从哪里来
• 当前服务到底连的是哪套数据库
• 逻辑删除字段的业务语义是什么

那它就很容易陷入一种“静态推理正确，动态结论错误”的状态。

这次我们项目里就连续遇到了：

• 代码已经改了，但运行中的服务没重启
• checkName 返回 true/false 的语义，调用方理解反了
• 数据库里能查到门店记录，但那条记录其实已经逻辑删除

这些都不是大算法问题，而是工程上下文没有被收束成一个可验证的工作台。

2）入口文档不该是经验大杂烩，而应该是导航页

以前很多项目的 AGENTS.md、模块说明文档，最后都会越写越长。
每次踩坑补一条，最后谁都不想看，AI 也很难稳定执行。

所以我这次顺手把项目里的规则做了一个调整：

• AGENTS.md 和 CLAUDE.md 保留高层原则
• 具体的联调、token、租户、契约规则下沉到 docs/testing/

这不是为了“文档好看”，而是为了让规则能被持续修正，而不是散落在三个地方互相漂移。

3）真正有价值的，不是“写了规则”，而是“规则能被验证”

如果规则只是：

• 显式传 tenantId
• 统一走网关
• 做真实 HTTP 测试

那它还是有点抽象。

真正有效的规则必须长成下面这样：

• 运营端接口测试时，直接向用户索取运营端 token
• 同一个 token，对照请求 tenantId=A/B
• 至少保留一条原始 HTTP 响应
• 必要时补查数据库解释“为什么接口返回这样”

一旦规则写到这个粒度，AI 和人都更难自欺欺人。

三、这次我把项目规则怎么改了

结合这次联调前后对比，我最后把项目里的规则改成了三层。

第一层：入口文档只讲方向，不再堆细则

我在项目根目录 AGENTS.md 和 goodsop-app-server/CLAUDE.md 里增加了一个明确入口：

• docs/testing/README.md
• docs/testing/admin-http-harness.md
• docs/testing/tenant-data-scope.md

意思很简单：
入口文档只负责告诉 AI“去哪儿看”，真正经常变化的实战规则集中维护。

第二层：把运营端 HTTP harness 写成可执行规则

这次新增的 admin-http-harness.md 里，我重点固化了几件事：

1. 所有运营端联调统一走 http://localhost:9999
2. 测试运营端接口时，必须直接问用户要 token
3. 同一轮验证里，优先用同一个 token 只切换 query tenantId
4. 每次改动至少保留 1 个真实业务接口的原始响应
5. 失败排查顺序固定为：连通性 -> 网关 -> Nacos -> 鉴权上下文 -> 业务代码/SQL

这几条看起来朴素，但非常关键。因为 agent 一旦没有这些硬边界，就会在“如何拿 token”“是不是该直连服务”“这个请求到底算不算验证”上浪费很多轮次。

第三层：把租户数据范围语义写明白

tenant-data-scope.md 里，我把这次最核心的结论直接写死了：

1. 后台管理接口的数据范围以显式传入的目标 tenantId 为准
2. TenantContextHolder 是上下文机制，不是后台业务真相
3. checkName/checkPhone 必须同时校验接口契约和逻辑删除语义

尤其是第三点，这次特别有代表性。

我们一开始看到有些门店名“库里明明有记录，接口却返回可用”，很容易怀疑代码没改对。
后来一查数据库才发现：那几条是逻辑删除记录。也就是说，数据库里有行，不等于业务上仍占用名称。

这个结论如果不被写进规则里，下次还会重复争论。

四、这次代码层面的前后对比，也很说明问题

如果只看代码，这次改动其实不算复杂，核心就是两件事。

改动前

• Controller 收到了 tenantId
• 但部分 service 逻辑还是依赖 TenantContextHolder
• checkName 的返回在失败时没有稳定给出 data=false
• 联调时容易把“请求头租户”“目标业务租户”“逻辑删除记录”混在一起

改动后

• admin/store/*、admin/consultant/* 显式把 tenantId 往下传
• 需要上下文的地方用 TenantBroker.applyAs(tenantId, ...)
• checkName 改成：
  • 可用：data=true
  • 不可用：data=false
• 真实接口回归不只看代码，还做了：
  • tenantId=5584 与 tenantId=1 对照请求
  • 门店新增、关店、员工新增、修改、离职
  • 必要时补查 PG 解释结果

这里最关键的，不是“把某个 if 改对了”，而是从“我觉得这样应该对”变成了“我能证明它对，而且能解释为什么”。

这就是 harness 的价值。

五、对我们这种业务项目来说，AI 真正缺的不是智商，而是工作台

很多人谈 AI Coding，喜欢把重点放在模型选择、prompt 技巧、上下文窗口大小。

这些当然重要，但我现在越来越觉得，对真实业务项目来说，下面这些东西更值钱：

1）可直接使用的环境入口

• 正确的网关地址
• 正确的 token 获取方式
• 正确的数据库连接信息
• 正确的日志和服务发现排查路径

2）可复用的验证脚本或验证模板

不是“你自己去测一下”，而是给出：

• 请求地址
• header
• body
• 对照 tenantId
• 预期差异

3）不会漂移的规则系统

很多团队的问题不是没有规则，而是规则散在聊天记录、群公告、项目文档、某个人脑子里。

一旦 AI 进场，这种问题会被放大得更厉害。
因为 AI 特别依赖“哪个文档才是 system of record”。

六、我准备继续往前做的，不只是写博客

这次规则改完以后，我更想补的是一套更完整的 harness，而不只是几段说明文档。

如果继续做，我下一步大概率会补这些东西：

1. scripts/verify-admin-store.sh
   • 自动完成 page/checkName/create/close
2. scripts/verify-admin-consultant.sh
   • 自动完成 page/checkPhone/create/update/resign
3. 运行态环境说明
   • 当前服务实际连接哪套 PG/Redis
4. 接口契约回归样例
   • 尤其是 data/code/msg 这种容易被误解的接口

因为写到最后我越来越确信一件事：

AI 工程化的竞争力，不是“谁的模型更像天才”，而是“谁先把自己的真实环境整理成一个不会误导 agent 的工作台”。

结语

OpenAI 那篇文章给我的最大提醒，是别把 agent 当成一个只会补代码的聊天机器人。

它更像一个能力很强、速度很快，但极度依赖环境质量的工程协作者。

如果你的环境是模糊的：

• 文档入口混乱
• token 获取方式混乱
• 租户语义混乱
• 接口契约混乱

那 AI 就会在这些噪音里反复打转。

但如果你把 harness 补起来，很多原来需要人肉盯着的事情，就会突然顺很多。

所以这次一个看似普通的 tenantId bug，最后给我的启发反而比 bug 本身更大：

以后优化 AI Coding，不只是继续追模型，也要继续做环境。

前两天看到一篇文章，讲一个团队是怎么被 OKR 搞废掉的。

我看完第一反应不是震惊，而是熟悉。太熟悉了。

这种剧情我不光看过，还真切经历过。大厂见过，创业公司也见过，而且每次套路都差不多。通常一开始业务还过得去，大家都忙着打仗，没人太在意考核这套东西。可一旦效益不好了，增长慢了，或者老板心里开始发虚了，OKR、KPI、周报、日报这些东西，往往就会突然变得重要起来。

然后团队就开始慢慢变形。

我在大厂第一次明显感受到这股味儿

那次大概是某年 Q3，公司股价跌了一波。上面开了几轮会，最后落下来一个词，叫“精细化管理”。

这词听着挺中性，甚至还有点高级，但翻译成人话，其实很多时候就是：开始抓考勤、抓周报、抓对齐、抓留痕。

我们组之前其实挺松的。活干完了，产品也上了，大家喘口气是很正常的。没什么事的时候，下午早一点走，也没人专门盯。那种状态未必完美，但至少大家注意力是在做事上的。

结果那段时间开始，节奏一下就变了。

• 每周一早上要站会，每个人说上周做了什么，这周准备做什么
• 周五要复盘，OKR 进度必须填进系统
• 日报、周报开始抄送更多层级
• 迟到早退这些以前没人太在意的事，也开始被认真统计

我当时带一个小团队，最明显的感受不是“管理加强了”，而是大家开始演了。

写代码的时间少了，写“证明自己在工作”的东西多了。注意，不是那种真正帮协作提效的文档，而是那种为了方便往上汇报、方便自证清白、方便出了问题别算到自己头上的文档。

有个同事我印象挺深。以前他遇到问题，直接拉人说两句，半小时可能就搞定了。后来不一样了，得先把背景写清楚，把问题写清楚，把影响写清楚，再写几个方案，最后约个会统一口径。一件原本半小时能搞完的事，最后能拖成两天。

我问他，为啥不直接说？

他说得也很实在：“现在不是讲流程、讲留痕吗？不留痕，到时候出事了怎么算？”

你看，这就是问题。

考核和管控一旦上强度，很多人的第一反应就不是怎么把事做好，而是怎么先保护自己。

创业公司的版本，通常更直接，也更荒诞

后来我去过一家创业公司，二十来号人，团队不大，早期氛围也不错。老板是技术出身，刚开始大家一起熬夜上线、一起救火，很多事都比较直接，没那么多讲究。

做到第二年，融资开始没那么顺，老板整个人的状态也肉眼可见地紧了起来。

先是开会说要“提高人效”，然后 HR 发下来一个表，让每个人填每天做了什么，以及时间大概怎么分配。再后来，周会慢慢变成一种带检查意味的一对一，老板会直接问：“你这周最核心的产出是什么？”

这种问法听着没毛病，但问题是，很多岗位的价值本来就不是按“这周交付了一个什么具体件”来体现的。

我印象很深的一次，是一个产品经理被问急了，说自己这周主要在协调资源、推沟通、解决卡点，没什么特别好拿出来展示的“具体产出”。

老板当时回了一句：“那就是没产出。”

那个产品经理第二周就离职了。

这件事我后来一直记得，不是因为它多戏剧化，而是因为它特别典型。很多管理动作一旦开始变味，最先出问题的，往往就是对“产出”的定义开始变窄了。凡是不好量化的、不能直接截图汇报的、没法马上写成条目的价值，都会被低估。

可现实不是这么运转的。

一个团队里，判断力、协调、补位、把模糊问题想清楚，这些东西很多时候比“今天做完了几个点”重要得多。只是它们更难写进表里。

我后来还跟那个老板聊过一次。我问他，咱们现在才这么点人，抓这么细，真的有必要吗？

他说：“我现在不知道每个人在干什么，心里没底。”

我当时回了一句：你靠抓考核，最后看到的，大概率也只是大家想让你看到的东西。

他没接这个话。

后来我越来越觉得，老板抓考核，很多时候不一定是为了提升效率，更像是在给自己的焦虑找一个抓手。

业务看不清楚，数据不好看，方向又没那么稳，人就会天然地想抓住一些“看得见、数得着、能检查”的东西。于是日报、周报、打分、排名、对齐，就都上来了。

问题是，这些东西最容易抓住的，通常都是表层动作。真正决定成败的那些东西，比如判断是不是对、协作是不是顺、试错是不是有效，反而不太容易量化。

最后就会变成一种很别扭的状态：大家都忙得很认真，但你真要问，忙出来了什么，好像又说不太清。

OKR 和 KPI 本身没原罪，真正容易出问题的是时机和动机

我不是那种逢考核必反的人。

说到底，OKR、KPI 这些东西本身只是工具。在大厂里，它们有存在理由。人多、层级多、链路长、信息天然不透明，你总得有一套机制让目标能往下拆，让结果能往上看。

工具没问题，问题往往出在它是怎么被用起来的。

我自己这些年看下来，有个规律挺明显：

• 业务顺的时候，考核往往没那么重要，很多时候走个形式
• 业务开始承压的时候，考核就会突然被强调
• 老板或者管理层心里没底的时候，考核会迅速精细化

这背后说明的事，其实挺现实的。

很多时候，考核不是拿来提升业绩的，而是拿来缓解焦虑的。

管理层焦虑，组织就会想办法把这种焦虑“落地”；一旦落到一线，通常就会变成更密集的汇报、更细的记录、更重的过程管理。

可焦虑这个东西，往下传一层，就很容易变成内耗。

因为一线接收到的信号不是“怎么把事做成”，而是“怎么证明我没问题”。

一旦组织进入这个状态，很多行为都会自然变形。目标会越定越保守，汇报会越写越漂亮，协作会越来越偏向自保，大家慢慢都知道这套东西不太对，但又只能继续陪着跑。

为什么这套东西一变味，团队很快就会失真

这点其实是我后来才慢慢想明白的。

正常情况下，目标管理本来应该是帮助团队聚焦的。你要解决什么问题，优先级是什么，阶段性打到哪里算过关，大家最好心里有数。

可一旦它和惩罚、排名、证明劳动强度这些东西绑得太死，目标管理就不再是“对齐工具”，而会慢慢变成“表演系统”。

人一旦意识到结果会直接影响评价，第一反应通常不是把目标定得更真实，而是把目标定得更安全。

于是：

• 能模糊的就模糊
• 能保守的就保守
• 能包装的就包装
• 能写得好看的就尽量写得好看

最后所有人都在做一件事：让系统里的自己看起来合理。

这个时候，你看到的数据可能越来越完整，表格可能越来越漂亮，但组织对真实情况的感知反而在下降。

这就是最麻烦的地方。

管理层以为自己抓得更细了，离真相更近了；可实际上，大家只是在更用力地经营“被看见的样子”。

我现在怎么看这件事

说实话，我也做过管理，完全能理解那种“我得知道团队现在到底什么情况”的冲动。团队一大，信息天然会打折，靠拍脑袋肯定不行。

但我现在越来越认同一件事：考核是手段，而且应该是偏后置的手段，不应该是你一上来最先拎出来的东西。

如果一个团队已经开始严重依赖考核来驱动，那通常说明前面已经有东西出问题了。可能是目标没讲清楚，可能是协同机制有问题，可能是信任不够，也可能是业务本身就进入了困难阶段。

这时候你再往上加考核，很多时候就像一个人发烧了，你不去找病因，先一把退烧药压下去。数字可能短期好看一点，动作可能短期整齐一点，但真正的问题还在。

更麻烦的是，这药吃多了，团队会虚。

人会越来越保守，越来越不愿意承担模糊地带的责任，越来越在意“这件事最后怎么评价我”，而不是“这件事到底值不值得做、该怎么做好”。

团队一旦走到这个方向，再想拉回来，成本很高。

给还在坑里的人几句实话

如果你在一家公司，突然发现考核变严了，流程变多了，周报越写越长，汇报越做越细，先别急着反思是不是自己不够努力。

先看业务。

如果业务是好的，这些东西很多时候只是形式主义，未必真会落到你头上，适当配合就行。

但如果业务已经明显承压，而组织又开始把很多精力放到考核、打分、追踪、排名这些事上，那你最好多留个心眼。因为这往往不是转机的开始，更像是管理层开始没底了。

你要判断的是，这到底只是短期波动，还是结构性问题。

如果只是短期波动，扛一扛也许能过去；如果是结构性问题，那你就要想清楚，这家公司后面是准备解决问题，还是准备把压力层层往下传。

这两者区别很大。

我后来不管选团队还是看组织，都会多看一眼：这地方到底是靠什么在驱动？是靠共识、目标和基本信任，还是靠考核、压力和持续盯人？

前者不一定就能成，但至少队伍还像个队伍。

后者短期可能会显得很有执行力，但时间一长，通常都会跑偏。

最后说一句。

OKR 也好，KPI 也好，本来都只是工具。工具本身不会自动变坏，但一旦它开始承担“缓解老板焦虑”“证明组织还在掌控中”这些额外功能，它就很容易变味。

所以很多时候，真正该问的不是“要不要强化考核”，而是：我们现在到底是在解决问题，还是在制造一种自己还控制得住局面的幻觉。

前阵子带团队，踩过一个挺典型的坑：我把上一家大厂里跑得还不错的一整套研发流程，原封不动搬到了创业公司。

我当时还挺有信心的，心想这些东西我都实战过，也验证过，怎么都不至于太差。结果三个月不到，团队效率没上去，情绪先下来了。大家活没少干，但整个人的状态都不对，流程像套在身上的一层壳，怎么动都别扭。

后来我才慢慢意识到一个事：流程这东西，不是越完整越高级，也不是越像大厂越专业，关键是合不合适。

上家公司是成熟中大厂，我们事业部有10个小组左右，通常8 到 9 个人的小组，角色配置相对完整，很多事情都有前提条件托着，标准敏捷那一套跑起来问题不大，比如我带的团队有9个人比现在创业公司带的人还多，工作得比较顺畅，所以我天然认为那套东西是好用的。可创业公司不是这个环境。人少、事杂、变化快，今天定的东西，明天可能就要推翻。这个时候你还想把流程铺得很满，最后大概率不是提效，而是添堵。

下面说几个我自己踩得比较实在的坑。

1. Jira 看板搞得太细，最后大家都在伺候看板

刚开始我把 Jira 也上了，而且沿用了上家公司那种拆法。一个需求要拆到设计、开发、测试、联调，最好还能估到小时，状态流转也尽量完整。

这套东西放在稳定一些的环境里，是有价值的。因为团队规模一大，协作链路一长，你不把信息结构化，很多事情就会乱。

当时我脑子里想的，其实差不多就是下面这种模式。一个板子看起来很清楚，列、卡片、负责人、状态，一眼望过去特别“专业”。

Jira 官方看板示意，来源：Atlassian。

但创业公司不是这么回事。

创业公司最常见的情况是，需求今天这么说，明天又换了；老板上午说先做 A，下午看了竞品又觉得 B 更重要。这个时候看板刚整理清楚，内容就过时了。大家不是在推进任务，而是在不停维护任务卡片，补字段、改状态、对齐口径。

慢慢地，团队开始烦这个东西。那种烦不是嘴上抱怨两句，而是你能明显感觉到，大家觉得在做无用功。

后来我们直接砍掉了这套细颗粒度管理，不再盯单个任务拆得多漂亮，只保留一个比较轻的整体节奏视图，主要看大的节点和关键事项。说白了，就是别再折腾一堆“过程看起来很美”的卡片，先把人从流程里解放出来。

我们后面实际落地的方式，反而很土：一张每日跟踪表，再配一张整体计划表。没有那么多状态流转，也没有那么多字段，但它足够直观，够我们这个阶段用。

这里先放两张我们当时真实在用的图（来源于产品负责人）：

改完以后，大家最直接的反馈不是“这个流程真先进”，而是终于不用天天填东西了。听着很朴素，但这往往说明方向对了。人重新把精力放回到做事本身，效率反而起来了。

2. 详设模板很完整，但完整本身就是负担

我以前的公司，详细设计是比较重视的，而且也确实有它的价值。系统复杂、协作方多、生命周期长，前面多花点时间把设计做扎实，后面能省不少事。

所以到了创业公司，我也想把这个习惯延续下来，要求大家按比较完整的详设模板来。虽然我知道不能照搬原来公司的但是我想着先试着暴露问题再调，
果然问题很快就出来了。

1. 团队成员几乎都没有正儿八经的写过详设，可能是在如今的软件开发，大家完全摒弃或者看不上很多年前的研发流程，所以不重视也不愿意接触。（但是经验告诉我存在既合理，你可以改进单不能完全否定，至少对我来说详设是让你想清楚你要做什么怎么做的过程，其实并不冲突）
2. 创业公司讲究的是快速验证，你先得证明这个东西值不值得做、能不能跑通、市场买不买单。有些模块的生命周期可能很短，有些模块就是很简单的CRUD。这个时候还要求每个需求都搞一份“大而全”的详设，性价比很低。

后来我的调整是，只保留重难点设计。

也就是说，不是不要设计，而是只在真正有必要的地方认真写。比如复杂流程、核心链路、容易出事故的地方，这些该写还是得写，而且要写清楚。至于那些简单页面、普通接口、试验性质的功能，就没必要搞得那么正式，很多时候口头对齐一下，加上关键点同步，也就够了。

模板也顺手砍掉了大半，能简就简。并比如只保留异常处理、数据库设计、关键算法、外部引入说明等章节。

这么改完以后，大家不会因为“要交一份文档”才去写东西，而是因为“这里确实需要想清楚”才写。这个差别挺大。前者容易把写文档变成任务，后者才更接近设计本身。

3. UI 评审流程太正式，节奏根本跟不上

我一开始还认真搭了 UI 评审流程，想着把产品、UI、前端这些角色都拉齐，尽量在正式评审里把问题消化掉。

这个思路本身没错。问题还是那个问题，环境不对。

创业公司很多时候拼的不是“流程是否完备”，而是“反应够不够快”。有时候你这边还在约会、准备材料、等人齐，外面竞品已经上线了。等你一轮会开完，讨论很充分，市场窗口也差不多过去了。

后来我就把这件事彻底做轻了。

多数情况下，前端和 UI 直接碰一下；如果产品逻辑也有争议，就三个人凑一起，当场对齐。能站着说完就别拉长会，能今天拍板就别拖到明天。先把主要分歧解决掉，剩下的小问题边做边收。

这样做当然没那么“规范”，但更符合创业公司的现实。

很多流程设计，表面上是在降低风险，实际上是在用确定性对冲不确定性。可创业公司真正的问题往往不是“讨论不够充分”，而是“动作不够快”。这时候流程越重，可能越错。

4. Sprint 很标准，但标准得有点不合时宜

我之前也试着在创业公司推标准 Sprint，单周也好，双周也好，站会、估时、回顾这些动作都想带起来。

现在回头看，方向有点想当然了。

标准 Sprint 背后有个很重要的前提，就是需求相对稳定，或者至少在一个迭代周期内，不要被打断得太厉害。这样团队才能围绕承诺来组织协作，节奏也才跑得顺。

可创业公司常常不是这种节奏。业务方今天提一个需求，明天就要看结果；线上出了点情况，当前优先级立刻变化；老板临时看到了一个机会，整个排期可能都要让路。

在这种情况下，固定迭代周期很容易从“管理工具”变成“现实阻力”。

你会发现团队嘴上还在讲 Sprint，实际上天天都在被插单。于是形式上很完整，执行上很别扭，大家最后既没享受到 Sprint 的好处，还多了一层心理负担。

后来我就不硬推固定迭代了，更偏向流动式开发。优先保证关键事情快速流过来、快速被处理掉，而不是先想办法把所有事情塞进一个看起来工整的周期里。

说白了，就是别为了流程的完整感，牺牲交付的真实节奏。

5. 工时估得越细，大家越焦虑

还有一个坑也挺常见，就是工时评估。

大厂里很多时候要做资源管理、项目协同、跨团队承诺，所以你会比较强调估时，甚至希望大家估得尽量准一些。这在某些环境下有它的合理性。

但在创业公司里，很多需求本身就带着不确定性。你连边界都没完全看清，非要提前精确承诺到某个点，最后大概率是两头难受。

一头是管理者以为自己拿到了确定性，另一头是执行的人背着一个并不靠谱的 deadline，越做越紧张。

尤其是一些复杂问题，真正难的地方往往在做之前并不能完全看出来。你要求团队给一个很精确的工时，看起来是在做计划，实际上可能是在制造幻觉。

后来我不再盯精确工时，而是更多给出一个大致时间窗口。该说明风险就说明风险，该留缓冲就留缓冲，不再逼着大家把很多本来就估不准的事情说得特别肯定。

结果挺有意思，精确度没那么好看了，但交付反而更可预期了，团队状态也轻松不少。

后来我真正想明白的几件事

1. 创业公司不是大厂缩小版

这个是最核心的一条。

很多人从大厂出来，容易有个潜意识：创业公司只是规模小一点，很多管理动作做轻一点就行了。

其实不是。

这两种组织在很多底层逻辑上都不一样。大厂更多追求稳定、可复制、可预测，流程是拿来放大协作效率、控制系统风险的。创业公司很多时候追求的是快速试错、快速验证、快速调整，它首先得活下来，然后才谈得上优化。

所以你不能简单理解成，大厂那套减配一下就能直接用。

2. 研发天然就不喜欢太重的文字工作

这个事挺现实的，但很多管理动作设计的时候经常假装看不见。

大多数研发真没那么喜欢填表、写一堆过程文档、反复同步那些价值不高的信息。不是因为懒，而是因为他们天然更愿意把注意力放在解决问题、写代码、做实现上。

所以减少无效文档，并不只是为了省时间，本质上也是一种尊重。你尊重一个岗位的工作重心，团队的配合度通常就会高很多。

当然，这不是说文档没用。我的意思只是，别把“有文档”当成默认正确，而是先想清楚，这份东西到底帮了谁，解决了什么问题，值不值得花这个成本。

3. 灵活不等于混乱，底线还是要有

创业公司不适合重流程，不代表什么都可以不要。

有些底线是不能退的，比如代码规范、版本管理、发布安全、线上稳定性这些东西。这些不是“有空再说”的选项，而是基本盘。没有这些，所谓灵活很容易滑成混乱，最后大家都在救火。

我现在更认同的一种状态是：在底线之上尽量灵活。

该守住的东西守住，剩下的就别绑太死。不要一边嘴上说着创业公司要快，一边又把团队拴进一堆并不适合当下阶段的流程里。

什么阶段适合什么模式

如果是成熟一些的中大型团队，人员配置完整，协作链条长，项目复杂度也高，那标准化流程通常是有收益的。它能提升协作效率，也能降低很多因为人多而带来的不确定性。

但如果是小型创业团队，尤其是不到 10 个人的研发团队，我现在的看法会很明确：怎么灵活怎么来，但底线要守住。

不是不要流程，而是只保留那些真正帮你提效的流程。凡是已经开始明显拖慢节奏、压坏情绪、制造无意义劳动的东西，就该果断砍。

最后的话

流程是手段，不是目的。

以前我总觉得，一个团队越专业，流程应该越完整。后来才发现，不是这么回事。真正成熟的团队，不是流程堆得最满的团队，而是知道什么该坚持，什么该省掉，什么阶段该用什么方法的团队。

说得再直白一点，创业公司最怕的不是“不够像大厂”，而是明明身子还很轻，却非要背上一整套大厂的装备。

那玩意儿穿在大厂身上可能是铠甲，穿在创业公司身上，很多时候就是负重。

引言

如果问题变成软件研发对年龄大还是对年龄小的有利好，其实应该用经验更好，但是用经验可能标题就没那么吸引人了。因为经验不等于经历（年龄）。无所谓了，先吸引人你们来看再说。

我相信分歧肯定会很小，因为现实摆在那儿。但是自从AI Coding兴起后，我就开始回过头来重新想这个问题。
AI Coding 起来了，到底是对“大龄程序员”更友好，还是对“年轻程序员”更友好？

如果把这个问题简化成“谁赢谁输”，我觉得答案会很刺耳：谁都可能赢，谁也都可能输。

因为 AI Coding 真正改变的不是“年龄”，而是“价值分布”。有些东西变得很便宜，有些东西反而更贵了。

我之所以对这个话题格外敏感，是因为我自己就是“所谓的大龄开发者”。
我在 34 岁那年带团队招人，脑子里一直有个挥之不去的词：35 岁魔咒。那种“明明还想继续写代码，但市场已经开始用年龄给你贴标签”的感觉，我太熟了。

我试着用结合我的经历来聊一聊，文章会比较长，当然这篇文章完全是我个人观点，我尽量少做评价，少被喷。我知道很有可能会有人喷我，但是还是劝一句不要上升高度不要过度带入 。

一、先别急着站队：这里的“年龄”到底在指什么？

所谓“大龄”“年轻”，很多时候说的不仅仅是身份证上的数字，而是三件事：

1. 经验的密度：你踩过多少坑、见过多少事故、做过多少取舍。
2. 学习的速度：新工具出来，你是“先试两把”，还是“先观望三个月”。
3. 机会的窗口：你能不能承受试错成本（时间、现金流、家庭压力、职业风险）。

AI Coding 这波浪潮，恰好会把这三件事的差异放大。

二、AI Coding 让什么变便宜了？

我先说结论：AI Coding 让“把想法变成可运行代码”的成本显著下降了。

具体来说，至少有三类东西变便宜了：

• 体力型编码：CRUD、胶水代码、重复的重构、样板工程、接口联调的模板化部分。
• 信息检索：查文档、找 API、翻 issue、找最佳实践的“第一跳”成本。
• 尝试与迭代：以前一个想法要半天验证，现在十分钟就能出个“像样的雏形”。

这意味着：只会“把代码敲出来”的能力，正在变成一种越来越普通的能力。

同时也意味着：真正能区分人的部分，正在往上游和下游移动。

• 上游：你能不能把问题定义清楚（需求/约束/边界/风险）。
• 下游：你能不能把结果负责到底（上线质量/稳定性/性能/安全/可维护/可演进）。

AI 写代码是快，但“负责”并不会自动发生。

三、我把同一个问题丢给了几个“顶尖模型”（无前置、无规则）

这里我做了个很“直白”的实验：不加任何前置说明、不设任何规则，就一句话提问，然后直接用它们各自的“最新模板 + 思考模式”拿答案。

原始截图我按顺序贴在下面：口吻不一样、结构不一样，但核心共识其实非常一致——

AI Coding 更像一个“放大器”，不是一张“对某个年龄段的免死金牌”。

我把模型回答里最有用的点，提炼成几条（是提炼，不是逐字复读）：

1）它们普遍认为：对“资深/大龄”的利好更直接

• 经验壁垒被放大：AI 能生成代码，但判断“这段代码对不对、架构合不合理、坑在哪里”，仍然更吃经验。
• 抹平体力优势：年轻人的手速、记 API、找资料的优势，被 AI 大幅抵消；这让大龄不用再去拼“码速”。
• 系统思维更值钱：很多模型都强调了“5 年后系统会怎样”“这个决策对业务的长期影响是什么”——这类能力更难被替代。
• 带团队能力升维：懂得把 AI 变成团队生产力的人，管理价值会更凸显（会用 AI 的人，不一定会让团队用好 AI）。

有个模型还给了一个很戳人的说法：AI 像“超级实习生”——写得快，但并不知道什么是对的；而资深的价值恰好就是“知道什么是对的”。

2）它们也提醒：对“年轻/新人”是双刃剑

• 入门门槛更低，但成长路径更模糊：以前靠 CRUD/修 bug 练基本功；现在 AI 秒生成，练功区变薄了。
• 容易形成“幻觉能力”：能把东西跑起来，但并没真正理解；一旦进线上、进复杂系统，就容易翻车。
• 更难证明自己：当“写出代码”变成普遍能力，面试/协作场景更看重你的思考、取舍、复盘与可靠性。

3）反过来：它们也给了年轻人一个“弯道超车”的入口

有的模型提了个很有意思的反转角度：年轻人如果从一开始就把 AI 当“外骨骼”（而不是“拐杖”），成长速度是指数级的。

我理解这句话的潜台词是：
你可以让 AI 替你省掉很多重复劳动，但你不能把“理解、设计、评审、负责”这四件事也省掉。

读完这些回答，我的第一反应其实不是“谁赢了”，而是更确认了：
AI Coding 放大的是你原本的优势和短板。

原始回答截图

（点击缩略图打开原图）

接下来我讲讲我的真实经历——因为我发现，模型说的这些点，在我的团队里几乎是一比一地出现过。

四、我自己的一个小样本：一支 98/99 团队，和一个“Y”

我先讲个我自己的经历，可能比空谈更有说服力。当然样本不包括我，虽然我可能是团队里工作量最大开发量可能也是最大的，但是因为我的职位以及以及工作能力上来说（削微有点不要脸哈），不太适合跟大家一起比。

我当前所在的公司在创业期，首先待遇和平台确实没法一步到位，但是我还是对招人的要求比较高，因为人没法招的多，所以我希望能进来的人都是能独当一面的。老板这边呢招人偏好很明确：更喜欢年轻的——觉得年轻人有活力、能拼、要的也没那么多。
说实话，这种想法我也能理解，甚至某种程度上我也认同：创业期确实更适配年轻人。但是因为我自己 34 岁，也是大龄开发，所以我也没有完全按所谓的35岁来卡简历，因为我上一家公司学到的很多东西都是从比我年龄还大的人身上学到的。

总之最终招人，团队里大多是 98、99 年左右的同学。另外还有一位年龄跟我相差不大、也算大龄开发者的同事，为了好说明，我就叫他 Y。

人招齐了，几个月共事下来，我被“刺激”得挺狠的——当然这个刺激主要是刺激我。

1）“年轻 = 有拼劲”？至少在我的团队里并不成立

团队里大多数人并没有我想象中那么有拼劲。

我观察下来，初步的感觉是有些同学的精力和注意力很多投放在短视频、短剧、游戏这些东西上。
我伸懒腰的时候瞄到一个同学：左边在 vibe coding，右边短剧放着。我当时一度分不清 vibe 的到底是哪边。

总之给我的体感是：状态不但不“拼”，反而有些消极和懈怠。可能更多的对他们来说就是类似流水线上那种计件工作一样，反正就是干一天就挣一天。（我估计很多人就要喷我了），就是我的意思是啥呢，当然我是old school哈，如果你不讨厌这份工作，那是不是对工作赋予一点其它的价值？比如对自己的锻炼、成长、成就感等

2）有了 AI Coding 以后，反而更暴露“设计与表达”的短板

为了避免 AI 滥用，我提了一个要求：重难点模块必须做设计。

我讲了要求，也给了模板，而且很直白地说：可以借助 AI 来完成设计任务。
但结果很现实：大多数人连“详设里应该写啥”都不清楚，UML 也不太会画，最终交付物一言难尽（说实话，Y 也没例外到哪去）。

我的感受是：很多人不是做不出来，而是压根没把心思放在“把问题讲清楚”以及“怎么解决”这件事上。

3）AI 让代码“飞起来”了，但 CR 一拉：屎山也能飞

有了 AI Coding，表面上代码写得很快。
但一到 Code Review，屎山代码一大堆：结构乱、边界不清、异常兜不住、测试缺失……一旦出 bug 就会变成“补丁套补丁”的恶性循环。

后来确实没办法，我让其中一位代码问题很严重的同学离开了。
他那块业务的 bug 多到修不完，修到后面甚至发现没法修——因为他自己找不到根本原因，只能不断打补丁，然后继续恶心循环。

我接手重构，前后花了差不多两周时间。

这里也顺带提一句：虽然 Y 的代码也有一些问题，但总体是可控的，不用担心暴雷。
我猜原因有两个：一是他比较遵守规则（我提的要求大多能做得比较到位），二是他大概有 10 年左右的开发经验，能在一定程度上“指导 AI 怎么干活”。

这三个刺激让我更确信一件事：AI Coding 把“写代码”这件事变得更容易了，但把“写对代码”这件事变得更重要了。

五、对年轻程序员：利好很大，但坑也很深

1）利好：入场门槛变低，反馈速度变快

对年轻人最直接的利好是：你可以更早做出完整作品。

以前你要先攒很久“基础设施能力”：脚手架、工程化、框架细节、各种配置地狱……
现在这些都能被 AI 帮你跨过去一大截。

于是你能更快进入“真正的战场”：

• 做一个能跑的产品/工具
• 去真实用户那里挨骂
• 在反馈里快速迭代

这对成长是好事，甚至是非常好的事。

2）坑：把“生成”误当成“掌握”

但年轻人也更容易踩一个坑：以为自己会了，其实只是 AI 会了。

你会发现项目能跑、功能能用，但一旦出现下面这些情况，就开始头皮发麻：

• 线上偶发 bug，日志看不懂
• 性能抖动，不知道从哪儿下手
• 需求一改，牵一发动全身
• 加一个看似简单的功能，最后变成“屎山滚雪球”

说得更直白一点：
AI 能帮你跳过一些“枯燥”，但跳得太狠，也会错过一些“肌肉训练”。

年轻人的关键不是“用不用 AI”，而是“能不能把 AI 变成你的教练，而不是代打”。

六、对大龄程序员：利好也很大，但会更“残酷”

1）利好：经验被放大，稀缺能力更稀缺

大龄程序员的优势，通常不在“手速”，而在“判断”：

• 方案取舍：这事该用微服务吗？该上 MQ 吗？该引入新框架吗？
• 风险感知：哪里会炸、什么时候会炸、炸了怎么兜底
• 复杂协作：跨团队、跨系统、跨角色（产品/运营/安全/法务）的落地能力

AI Coding 让“写”的成本下降后，判断的价值反而会更凸显。

因为系统越容易被搭起来，系统也越容易被搭坏；
上线越快，事故也来得越快。

这类场景里，经验不是包袱，经验是护城河。

2）残酷：如果你把自己定义成“高级码农”，会被挤压得很厉害

更残酷的一面是：有一类“大龄”会很难受——
不是因为年龄大，而是因为他过去十年把自己训练成了“熟练工”：

• 熟练地堆功能
• 熟练地应付需求
• 熟练地修修补补

当 AI 把“熟练工”这块压到极致性价比后，这条赛道会非常拥挤。

不是 AI 淘汰大龄，而是“只剩熟练”会被淘汰。

七、真正的分水岭：谁能“问对问题 + 做对取舍 + 负责结果”

如果要我给一句话版本的答案：

AI Coding 的利好，不属于某个年龄段，属于“能把 AI 当成杠杆的人”。

你能不能：

• 把问题说清楚（目标、约束、边界、验收标准）
• 把方案选对（可维护、可观测、可扩展、成本可控）
• 把结果交付（线上稳定、可追踪、能迭代、能复盘）

这三件事，AI 都能参与，但 AI 都不能替你承担。

八、我给两类人的具体建议（尽量可执行）

给年轻程序员的 5 条

1. 把 AI 当“解释器”：让它解释你不懂的代码、让它画调用链、让它写测试，而不是只让它“写功能”。这方面稍微用点心就会发现有一堆skill或者提示词可提升让AI写”准“的能力。
2. 刻意练基本功：调试、日志、性能、并发、网络、数据库索引，这些是你未来十年的复利。
3. 做真实项目：哪怕是一个很小的工具，能被别人用，比刷十套题更接近现实。
4. 训练问题定义：每次让 AI 干活前，开启PLAN模式，先反复交流，让双方都搞“我到底要什么”，这是最值得投入的能力。
5. 保留手写能力：不是为了炫技，是为了在关键时刻你能掌控复杂度。

给大龄程序员的 5 条

1. 别抗拒工具，抗拒的是落后感：先用起来，哪怕从“写测试/写文档/写脚本”这种低风险场景开始。比如我几乎试遍了主流的所有AI模型和AI工具，比如Codex、Claude code、Opencode、GLM、Minimax、Antigravity、Cursur、kimi-cli、Kiro等，每次都很兴奋，我会不断用他们在我的工作任务中尝试，最终筛选出来我最顺手的。（当然这个过程又是另一个故事了）。
2. 把经验产品化：把你脑子里的“事故清单”“选型原则”“排障套路”写出来，变成团队资产。你要能快速的把你多年的积累分类并补全（可靠AI），随时抽取出来给到AI使用。
3. 强化架构与质量话语权：可观测性、灰度、回滚、SLA、成本模型……这些会越来越值钱。
4. 练提示词，但更要练评审：你不是比谁会 prompt，你是比谁能看出生成代码的坑。你要能评估AI的方案是否合理。
5. 把自己从“写代码的人”升级为“交付结果的人”：能把事情做成的人，永远稀缺。

结尾

当然看到这儿，肯定有人会说我是在和稀泥一顿输出孟如虎，但是又好像啥没说，那咋可能呢，我可是很不喜欢和稀泥的。

所以回到最开始的问题：AI Coding 的兴起，是对谁的利好？

我的答案比较乐观是：利好年龄大的开发者，因为在我看来，从当前现状分析，就算各有利好，那就算趋近55开了，相比之前的3/7开甚至1/9开是不是提升？当然还是得补一句和稀泥的话。
对愿意重新学习的人利好，对愿意承担结果的人利好，对愿意把经验变成杠杆的人利好。

年龄只是你当前的状态，AI 才是这场变化的放大器。

你站在放大器的哪一边，取决于你接下来三个月怎么过。
我自己 34 岁那次带队招人、带队落地，被那一轮“刺激”按在地上摩擦之后，反而更确定了：真正的安全感不是年龄给的，是你把“负责结果”的能力练出来之后，自然长出来的。

当然到底工作能力高低应该怎么评价，那就是另一个故事了。如果有幸可以发挥，我后续会来一篇。

前几天刷到个帖子，给我看傻了。

一个开发老哥，用 AI 智能体集群，一个人干了整支开发团队的活。不是 Demo，不是 toy project，是正经在跑的 B2B SaaS，还在产生真实收入。

这数据太离谱了

单日最高 94 次代码提交，日常平均 50 次。

最快 30 分钟合并 7 个 PR，需求从提出到上线通常当天搞定。

关键是，这些代码直接变成真金白银的 经常性收入。

整套系统跑下来，月均成本 190 美元，最低 20 美元就能起步。

这哥们儿叫 Elvis，已经把架构开源了。核心是个叫 OpenClaw 的智能体编排系统。

核心痛点：上下文窗口不够装

直接拿 Codex 或 Claude Code 写代码？那是老黄历了。

问题在于上下文窗口的零和博弈——代码塞多了，业务逻辑装不下；塞满客户历史，又看不懂代码库。

就像拿个小杯子装东西，代码和业务背景只能二选一，怎么都不够使。

破局的关键是：把业务跟代码解耦。

OpenClaw 是干嘛的

简单说，它是人和大模型之间的”翻译官”。

这个编排器叫 Zoe，直接读 Obsidian 里的客户数据、会议记录、历史决策，把业务上下文翻译成机器能懂的提示词。

有意思的是，这跟 Stripe 之前披露的 Minions 系统思路很像，但完全跑在本地。

工作流：极度克制的自动化

需求确定后，Zoe 干这几件事：

1. 调管理员 API 解除客户限制
2. 拉生产数据库的只读配置塞进提示词
3. 给每个智能体分配独立的 git worktree 和 tmux 会话

1
2
3
4
5

git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
cd ../feat-custom-templates && pnpm install
tmux new-session -d -s codex-templates \
  -c /Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates \
  $HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high

然后唤醒编码智能体：

1
2
3
4
5
6
7
8

codex --model gpt-5.3-codex \
  -c model_reasoning_effort=high \
  --dangerously-bypass-approvals-and-sandbox \
  "Your prompt here"

claude --model claude-opus-4.5 \
  --dangerously-skip-permissions \
  -p "Your prompt here"

tmux 这个用法挺妙

发现方向偏了，不用杀进程，直接往终端发指令强行纠偏：

1
2

tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

任务状态实时写进 .clawdbot/active-tasks.json：

1
2
3
4
5
6
7
8
9
10
11
12

{
  id: "feat-custom-templates",
  tmuxSession: "codex-templates",
  agent: "codex",
  description: "Custom email templates for agency customer",
  repo: "medialyst",
  worktree: "feat-custom-templates",
  branch: "feat/custom-templates",
  startedAt: 1740268800000,
  status: "running",
  notifyOnComplete: true
}

跑完自动更新：

1
2
3
4
5
6
7
8
9
10
11
12

{
  status: "done",
  pr: 341,
  completedAt: 1740275400000,
  checks: {
    prCreated: true,
    ciPassed: true,
    claudeReviewPassed: true,
    geminiReviewPassed: true
  },
  note: "All checks passed. Ready to merge."
}

监控：低成本轮询

用 cron 每 10 分钟跑一次确定性 Shell 脚本。

.clawdbot/check-agents.sh 检查会话状态、调 gh cli 验证 CI，卡住了自动重试最多 3 次。

代码提交门槛很高：TypeScript 检查、单元测试、Playwright 端到端测试，一个都不能少。UI 改动还必须带截图，否则 CI 直接拦下。

Code Review：三模型交叉验证

这套审查机制挺有意思：

• Codex：抓逻辑错误、竞态条件这些核心坑
• Gemini：盯安全漏洞和架构扩展性
• Claude Code：打辅助，做冗余验证

三个模型互相盯着，比单一模型靠谱多了。

改良版拉尔夫循环

底层跑的是改良版拉尔夫循环。

Zoe 不是机械地复用静态提示词，而是带着全局业务上下文去救场，动态调优失败的节点。

更狠的是，它还能自己找活干：

• 早上扫 Sentry 日志，自动派修复工单
• 开完会解析记录，提取功能需求
• 晚上梳理 git 日志，生成更新文档

基本不用人催，自己就把活儿干了。

模型分工很明确

不同模型干不同的事，不瞎折腾：

• Codex：90% 的复杂后端和跨文件重构
• Claude Code：前端构建和 git 操作
• Gemini：UI 设计环节输出规范文档

各干各的擅长的，效率最高。

部署：10 分钟搞定

最爽的是部署。把架构文档扔给 OpenClaw，10 分钟 内全自动完成脚本生成和目录搭建。

基本上就是”一键开店”的感觉。

唯一的瓶颈：内存

现在卡脖子的只有硬件内存。

每个独立工作树加并发编译环境，都在疯狂吃内存。

16GB 的 Mac mini 并发 4-5 个智能体就开始Swap了。

老哥已经下单了 3500 美元的 M4 Max Mac Studio（128GB 内存），准备突破并发上限。

一人公司时代真要来了

基于这套系统做的公关工具 Medialyst.ai 已经在落地。

不是概念验证，是真的在赚钱的一人企业。

我的一点想法

说实话，这事儿给我的震撼挺大的。

不是那种”AI 好牛逼”的震撼，而是”原来真的可以这么干”的震撼。

单人开发团队不是空谈，已经有人跑通了。关键不是某个模型多强，而是怎么让多个模型协同起来。

OpenClaw + Codex/CC 这个组合，给了一个很清晰的方向：

编排比模型本身更重要。

传统软件开发那套流程正在被重塑。以前需要产品经理、开发、测试、运维一堆人干的事，现在一个人加一堆智能体就能搞定。

一人公司的时代，可能比我们想象的来得更快。

参考链接：https://x.com/elvissun/status/2025920521871716562

缘起

最近发现一个 GitHub 项目 wshobson/agents，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。

让我震撼的几个数字：

• 112 个专业 AI Agent
• 16 个多智能体工作流编排器
• 146 个 Agent Skills
• 79 个开发工具
• 72 个独立插件

这已经不是”用 AI 辅助编程”了，这是用 AI 团队替代开发团队。

核心架构：插件化设计

wshobson/agents 最聪明的设计是插件化。

它不是给你一个大而全的系统，让你把所有东西都加载进来。而是拆成 72 个独立的插件，每个插件只做一件事，但做到极致。

为什么要插件化？

上下文窗口是有限的资源。如果你一次性加载 112 个 Agent 和 146 个 Skills， token 消耗会爆炸。

插件化的解决方案：按需加载。

举个例子：

1
2

# 安装 Python 开发插件
/plugin install python-development

这个插件只加载：

• 3 个 Python 专业 Agent
• 1 个脚手架工具
• 16 个专业 Skills

总共约 1000 个 token，而不是整个市场的几万 token。

插件的分类

72 个插件分成 24 个类别，每个类别 1-6 个插件：

这种结构的好处是：想用啥装啥，绝不多加载。

三层模型策略

这个项目最让我印象深刻的是它的模型分层策略。

不是一刀切地用同一个模型，而是根据任务复杂度分配不同的 Claude 模型：

为什么 Opus 4.6 负责关键任务？

几个硬指标：

• SWE-bench 80.8% — 行业领先
• 复杂任务 token 减少 65%
• 最适合架构决策和安全审计

虽然 Opus 单价高（$5/$25 每百万 token），但因为 token 效率更高，实际成本往往更低。

Tier 2 的灵活性

Tier 2 的 Agent 标记为 inherit，意思是使用你当前会话的默认模型。

怎么用？

1
2
3

# 启动会话时指定模型
claude --model opus    # 需要高强度时用 Opus
claude --model sonnet  # 日常开发用 Sonnet

这样你可以根据当前任务灵活选择，不用改配置。

Agent Teams：真正的并行工作流

这是我觉得最实用的功能：多智能体并行。

安装 Agent Teams 插件：

1

/plugin install agent-teams@claude-code-workflows

7 个预设团队

实战示例：并行代码审查

1

/team-review src/ --reviewers security,performance,architecture

这个命令会：

1. 启动 3 个审查 Agent（安全、性能、架构）
2. 每个 Agent 独立审查代码
3. 汇总结果，生成综合报告

传统的代码审查是串行的：一个人看完再给下一个人。现在是三个人同时看，时间从几小时缩短到几分钟。

实战示例：假设驱动调试

1

/team-debug "API returns 500" --hypotheses 3

系统会：

1. 生成 3 个关于 500 错误的假设
2. 每个假设分配一个 Agent 去验证
3. 并行执行验证
4. 返回最可能的根因

这比一个人一个个尝试 hypotheses 快多了。

Conductor：项目管理的 AI 化

另一个强大的插件是 Conductor，它把 Claude Code 变成了项目管理工具。

1

/plugin install conductor@claude-code-workflows

核心工作流

1. 交互式项目初始化

1

/conductor:setup

这个命令会：

• 创建产品愿景
• 确定技术栈
• 定义工作流规则
• 生成代码风格指南

2. 基于 Track 的开发

1

/conductor:new-track

生成规格说明和分阶段实施计划。

3. TDD 工作流

1

/conductor:implement

执行任务，带验证检查点。

4. 语义化回滚

1

/conductor:revert

按逻辑单元回滚（track、phase 或 task）。

状态持久化

项目上下文跨会话持久保存。你今天设置的项目，明天打开 Claude Code 还能继续。

Skills：渐进式知识披露

146 个 Skills 是 wshobson/agents 的知识层。

每个 Skill 是一个专门的知识包，遵循渐进式披露架构：

Skills 的分类

语言开发：

• Python（5 个）：async 模式、测试、打包、性能、UV 包管理
• JavaScript/TypeScript（4 个）：高级类型、Node.js 模式、测试、ES6+

基础设施：

• Kubernetes（4 个）：manifest、Helm、GitOps、安全策略
• 云基础设施（4 个）：Terraform、多云、混合网络、成本优化
• CI/CD（4 个）：流水线设计、GitHub Actions、GitLab CI、密钥管理

AI/ML：

• LLM 应用（8 个）：LangGraph、Prompt Engineering、RAG、评估、embedding、相似性搜索、向量调优、混合搜索

区块链：

• Web3（4 个）：DeFi 协议、NFT 标准、Solidity 安全、Web3 测试

激活示例

当你使用 Python 开发插件时，相关 Skills 会自动激活：

1
2
3
4
5
6

用户："创建一个 FastAPI 微服务"

系统激活：
- async-python-patterns
- python-testing-patterns  
- uv-package-manager

你不需要手动选择，系统根据上下文自动加载。

实战：从零搭建全栈功能

让我用一个完整示例展示这套系统的能力。

场景：添加用户认证功能

传统方式：

1. 设计数据库表（1 小时）
2. 写后端 API（4 小时）
3. 写前端页面（4 小时）
4. 写测试（2 小时）
5. 代码审查（1 小时）
6. 部署（1 小时）

使用 wshobson/agents：

1
2
3
4
5
6
7

# 安装必要插件
/plugin install full-stack-orchestration
/plugin install python-development
/plugin install backend-development

# 启动全栈编排
/full-stack-orchestration:full-stack-feature "user authentication with OAuth2"

系统会协调 7+ 个 Agent：

1. backend-architect → 设计 API 架构
2. database-architect → 设计数据库 schema
3. frontend-developer → 实现登录 UI
4. test-automator → 生成单元测试和 E2E 测试
5. security-auditor → 安全审计
6. deployment-engineer → 配置部署
7. observability-engineer → 设置监控

这些 Agent 并行工作，不是串行。

结果：

• 时间从 13 小时缩短到 30 分钟
• 包含安全审计和测试覆盖
• 自动部署和监控

安全加固示例

1
2

/plugin install security-scanning
/security-scanning:security-hardening --level comprehensive

这个命令会启动多 Agent 安全评估：

• SAST 扫描
• 依赖项扫描
• 代码审查
• 合规检查

Python 项目脚手架

1
2

/plugin install python-development
/python-development:python-scaffold fastapi-microservice

自动激活的 Skills：

• async-python-patterns - AsyncIO 和并发
• python-testing-patterns - pytest 和 fixtures
• uv-package-manager - 快速依赖管理

生成的项目包含：

• 生产级 FastAPI 结构
• 异步模式最佳实践
• 完整的测试套件
• Dockerfile 和 docker-compose
• CI/CD 配置

成本分析

大家最关心的：这得花多少钱？

模型成本

实际使用成本

一个小型项目团队（3-5 人）的月度估算：

• 日常开发（Sonnet）：$50-100/月
• 关键架构审查（Opus）：$30-50/月
• 自动化任务（Haiku）：$10-20/月

总计：$90-170/月

对比：

• 一个初级开发者的工资：$3000-5000/月
• 这个系统的成本：1/30

ROI 非常明显。

省钱技巧

1. 用 inherit 模式灵活选择模型

   • 日常开发用 Sonnet
   • 关键任务切换到 Opus

2. 合理拆分任务

   • 大任务拆成小任务
   • 减少单次调用的 token 消耗

3. 利用 Skills 的渐进披露

   • 只在需要时加载详细知识
   • 避免不必要的资源加载

与 OpenClaw 的对比

有人可能会问：这个和之前写的 OpenClaw 有什么区别？

我的建议：

• 如果你已经在用 Claude Code，直接上 wshobson/agents
• 如果你需要更灵活的编排或有特殊需求，考虑 OpenClaw
• 两者也可以结合：用 OpenClaw 做高层编排，wshobson/agents 做具体执行

个人思考

用了一段时间 wshobson/agents，有几个感触：

1. 专业化分工是趋势

不是让一个大模型做所有事，而是让多个专业 Agent 各做各的。

就像真正的开发团队：

• 架构师做设计
• 后端写 API
• 前端做界面
• 测试写用例
• 运维管部署

AI Agent 也在走这条路。

2. 编排层的价值被低估了

很多人关注单个 Agent 的能力，但编排层才是放大器。

好的编排可以让 10 个普通 Agent 发挥 100 个 Agent 的效果。

3. 上下文管理是关键

wshobson/agents 的插件化和渐进披露设计，本质上是在解决上下文管理问题。

有限的上下文窗口 → 按需加载 → 最大化利用

这是所有 AI 系统都要面对的挑战。

4. 成本可控比想象中容易

很多人被 Opus 的价格吓到，但：

• 大部分任务用 Sonnet 就够了
• Opus 的 token 效率更高
• 合理分层后，实际成本很低

5. 未来是”人机协作团队”

不是 AI 替代人类，而是人类+AI 团队替代传统团队。

一个产品经理 + wshobson/agents = 一个完整开发团队

这不是科幻，是现在就能实现的事。

如何开始

第一步：添加插件市场

1

/plugin marketplace add wshobson/agents

第二步：浏览可用插件

1

/plugin

第三步：安装你需要的

1
2
3
4
5
6
7
8
9
10
11
12

# 基础开发
/plugin install python-development
/plugin install javascript-typescript

# 代码审查
/plugin install comprehensive-review

# 全栈工作流
/plugin install full-stack-orchestration

# 多智能体团队
/plugin install agent-teams

第四步：开始使用

1
2
3
4
5
6
7
8

# 并行审查
/team-review src/

# 全栈功能开发
/full-stack-orchestration:full-stack-feature "your feature"

# Python 脚手架
/python-development:python-scaffold your-project

写在最后

wshobson/agents 让我看到了 AI 辅助开发的下一个阶段。

不是更好的单轮对话，不是更长的上下文窗口，而是系统化的多智能体协作。

112 个 Agent、16 个编排器、146 个 Skills — 这些数字背后是一个清晰的愿景：

让一个人拥有整个团队的能力。

这不是取代人类，而是给人类超能力。

你仍然是决策者、架构师、审查者。但执行层面的工作，可以交给这个永不疲倦的 AI 团队。

未来已来，只是分布不均。

参考

• 项目地址：https://github.com/wshobson/agents
• Claude Code 文档：https://code.claude.com
• Agent Teams 文档：项目中查看 /agent-teams
• Conductor 文档：项目中查看 /conductor

背景

最近在 GitHub 上看到个项目,叫 Strix。

看了一下,这玩意挺有意思的。像黑客一样的 AI 智能体,用来做安全测试。

简单说,就是一群 AI 代理,像黑客一样攻击你的应用。做个记录，方便后续需要时查看使用。

Strix 是什么

根据官方介绍:

Strix 是开源的 AI 智能体安全测试平台。

它的核心思想:让多个 AI Agent 协作,自动发现和修复安全漏洞。

核心特点

• 多智能体协作:多个 Agent 一起工作
• 真实验证:用 PoC 概念验证漏洞
• 自动修复:生成可修复的 PR
• 快速反馈:CI/CD 集成
• 低误报:减少假阳性

核心能力

1. 应用安全测试

Strix 可以对任何应用进行全面的安全测试:

• 漏洞发现:自动识别常见漏洞
• 渗透测试:模拟真实攻击场景
• 验证测试:PoC 验证
• 安全审计:全面安全评估

2. Agent 协作

这是 Strix 的核心。

多个 AI Agent 像黑客团队一样工作:

• 有些负责扫描
• 有些负责攻击
• 有些负责验证
• 有些负责报告生成

好处:

• 并行处理,速度快
• 全覆盖,不遗漏
• 模拟真实攻击,更精准

3. 代码分析

静态和动态代码分析能力:

• 静态分析:SAST/DAST
• 依赖检查:第三方库安全扫描
• 配置审计:安全配置检查
• 代码质量:安全相关代码质量检查

4. Web 安全

针对 Web 应用的安全测试:

• XSS 检测:跨站脚本攻击
• CSRF 防护:跨站请求伪造
• SQL 注入检测:数据库注入攻击
• 命令注入:系统命令注入攻击

5. API 安全

API 安全测试能力:

• 认证测试:API 认证机制
• 授权测试:API 授权和权限
• 速率限制:API 限流测试
• 数据泄露:敏感数据泄露检测

快速开始

环境要求

• Docker 运行
• LLM API Key (OpenAI/Anthropic/Google 等)
• Python 3.8+

安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 克隆仓库
git clone https://github.com/usestrix/strix.git

# 进入目录
cd strix

# 安装依赖
pip install -r requirements.txt

# 配置 API Key
export STRIX_LLM="openai/gpt-4"
export LLM_API_KEY="your-api-key"

# 运行首次扫描
strix --target ./your-app-directory

配置说明

首次运行会自动:

• 拉取 Docker 镜像
• 启动沙箱环境
• 运行安全扫描
• 生成报告

使用场景

场景一:GitHub 仓库安全测试

1
2

# 扫描 GitHub 仓库
strix --target https://github.com/your-org/your-repo

Strix 会:

• 扫描代码仓库
• 检查依赖安全问题
• 生成安全报告
• 创建修复 PR

场景二:本地代码库测试

1
2

# 扫描本地代码
strix --target ./my-codebase

扫描:

• 所有 Python/JavaScript 文件
• 配置文件安全检查
• 硬编码密钥检测
• 敏感信息泄露检测

场景三:Web 应用渗透测试

1
2

# 渗透测试
strix --target https://your-app.com --mode penetration

Agent 会:

• 自动发现登录页面
• 尝试常见攻击
• 测试权限绕过
• SQL 注入测试
• XSS 攻击测试

场景四:自动化 CI/CD 集成

1
2

# CI/CD 安全测试
strix --target ./ci-cd-pipeline

测试:

• GitHub Actions 安全配置
• 工作流注入攻击测试
• 密钥泄露检测
• 恶意依赖检测

网络上的实践案例

案例:发现高危漏洞

有安全团队分享了 Strix 的使用经验:

1. 零日漏洞发现

   • Strix 在测试某应用时
   • 发现了一个未公开的漏洞利用
   • 该漏洞被标记为 0day
   • 生成了详细的 PoC

2. 自动化漏洞挖掘

   • 传统的手工挖掘需要数周
   • Strix 用 Agent 自动挖掘
   • 一周内发现 10+ 个逻辑漏洞

3. 误报率降低

   • 静态工具误报率通常 20-30%
   • Strix 通过 AI 验证降低到 3-5%
   • 大幅减少人工审核时间

案例:提高测试效率

某开发团队的对比:

效率提升非常明显。

Strix 平台

除了开源 CLI 工具,Strix 还提供了完整平台:

app.strix.ai

• 可视化界面:Web 界面管理测试项目
• 多项目管理:同时管理多个测试项目
• 团队协作:团队成员共同参与
• 报告生成:自动生成美观的安全报告
• 历史追踪:测试历史和漏洞追踪

功能特性

• 实时监控:测试进度实时查看
• 通知提醒:关键发现自动通知
• 导出功能:多格式导出报告
• API 访问:开放 API 供集成

企业版特性

• SSO 单点登录
• 自定义合规报告
• 专属支持
• 私有化部署

技术架构

前端

• React:用户界面
• Tailwind CSS:样式框架
• Vite 5:构建工具

后端

• FastAPI:Python Web 框架
• Celery:任务队列
• PostgreSQL:数据库

AI 核心

• 多模型支持:支持多个 LLM Provider
• Agent 编排:智能体协调和任务分配
• 知识库:安全知识库和攻击模式

安全沙箱

• Docker 隔离:每个测试运行在独立容器
• 网络隔离:受控网络环境
• 资源限制:CPU/内存限制
• 日志审计:完整操作日志

优势和限制

优势

1. 开源免费:完全开源,免费使用
2. 快速上手:配置简单,5 分钟开始测试
3. 自动化程度高:大部分测试自动完成
4. 社区活跃:GitHub 上活跃,持续更新
5. 多供应商支持:不绑定单一 API,成本可控

局限性

1. LLM 成本:依赖付费 LLM API,测试成本高
2. 技术门槛:需要一定 AI 和安全知识
3. 误报率:虽然降低到 3-5%,但仍需人工验证
4. 资源消耗:多 Agent 并发,资源消耗大
5. 学习曲线:需要学习 Strix 的使用方式

适用人群

安全团队

• 适合需要提高测试效率的团队
• 特别是 AI 驱动的安全测试
• 需要处理大量漏洞报告

开发团队

• 适合想要自动化安全测试的团队
• 可以作为 CI/CD 流程的一部分
• 需要定期进行安全审计的团队

AI 研究者

• 适合研究智能体安全的研究
• 可以作为研究平台使用
• 需要测试新攻击向量的团队

实用建议

1. 从小规模开始

不要一上来就想大规模部署。

建议:

• 先用 Strix 测试一个小项目
• 熟悉工作流
• 验证效果
• 再逐步扩大规模

2. 重视人工验证

虽然 AI 自动化,但人工验证仍然重要。

建议:

• 重点关注高影响漏洞
• 认真审核 AI 发现的问题
• 建立验证标准和流程

3. 合理控制成本

LLM API 成本不低。

建议:

• 选择性价比高的模型
• 用 Strix Router 统一管理多个 Provider
• 设置合理的速率限制
• 监控使用量和成本

4. 结合传统工具

Strix 不是要完全替代传统工具,而是补充。

建议:

• SAST/DAST 工具继续使用
• Strix 用于 Agent 协作和智能分析
• 两者结合,发挥各自优势

5. 学习和贡献

Strix 是开源项目,鼓励社区贡献。

建议:

• 阅读官方文档
• 学习源代码
• 提 Issue 和 PR
• 分享使用经验

写在最后

Strix 代表了AI 驱动的安全测试新方向。

它的核心思想:用一群 AI Agent,像黑客团队一样协作,自动发现和修复漏洞。

优势:

• 测试速度快
• 覆盖率高
• 误报率低
• 自动化程度高

需要注意:

• LLM 成本不低
• 有一定学习曲线
• 仍需人工验证

对于安全团队、开发团队、AI 研究者,都值得关注。

如果你在做 AI Agent 相关开发,Strix 提供了一个很好的参考。

参考

• 项目地址: https://github.com/usestrix/strix
• 官方文档: https://docs.strix.ai
• 平台地址: https://app.strix.ai
• Discord 社区: https://discord.gg/strix-ai