doc: 新增文章，探讨 AI 编程

source/_drafts/戒掉ChatGPT的30天，我更怕的不是效率下降，而是大脑开始偷懒.md

@@ -0,0 +1,290 @@
+---
+title: 戒掉 ChatGPT 的 30 天，我更怕的不是效率下降，而是大脑开始偷懒
+author: Gamehu
+date: 2026-03-14 11:30:00
+tags:
+  - AI
+  - ChatGPT
+  - 认知卸载
+  - 效率工具
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">认知</span>
+</div>
+
+前两天我看到一篇挺火的英文文章，标题很吓人：
+
+[I Stopped Using ChatGPT for 30 Days. What Happened to My Brain Was Terrifying.](https://levelup.gitconnected.com/i-stopped-using-chatgpt-for-30-days-what-happened-to-my-brain-was-terrifying-70d2a62246c0)
+
+老实说，这类标题我一般会先打个问号。  
+“停用 30 天”“大脑变化”“很可怕”这套组合，一看就很容易往情绪化方向跑。
+
+但我读完之后，反而被它戳中了一点：
+
+<span class="highlight-text">真正值得警惕的，不是 AI 让你变懒，而是你开始默认“这类思考不值得自己做了”。</span>
+
+这两年我们聊 AI，最常见的叙事要么是“效率起飞”，要么是“工作要没了”。可对普通人、尤其是天天写字、写代码、写方案的人来说，更真实的变化可能是第三种：
+
+**你没有失去能力，你只是越来越少亲自调用它。**
+
+这个差别看起来很小，后劲却很大。
+
+---
+
+## 一、最危险的不是用 AI，而是不知不觉把“起步思考”也外包了
+
+原文里有个细节我很有共鸣。
+
+作者说，他写一封普通邮件，刚写到第三句话，就下意识想打开 ChatGPT。不是写代码，不是做复杂研究，就是一封邮件。
+
+看到这里我第一反应不是“夸张”，而是“太真实了”。
+
+因为这事现在真的很普遍。
+
+- 标题不会起，先问 AI
+- 回复消息要斟酌一下，先问 AI
+- 脑子里有个模糊想法，懒得整理，先丢给 AI
+- 看一篇长文没耐心，先让 AI 总结
+- 写个 SQL、正则、脚本，先让 AI 起草
+
+这些动作单个看都没问题，甚至很合理。问题在于，一旦它变成默认动作，你的大脑会慢慢形成一种新习惯：
+
+**先外包，再判断；先拿答案，再决定自己要不要理解。**
+
+这会直接吃掉一种很关键的能力，叫“起步思考”。
+
+所谓起步思考，不是高深推理，而是你面对一个问题时，先自己把轮子转起来的能力。比如：
+
+- 先粗暴列 3 个可能原因
+- 先写一个很丑但可用的开头
+- 先凭经验给出一个不完美判断
+- 先自己组织一版表达，再去优化
+
+以前这些动作虽然笨，但它们是大脑热身的一部分。现在很多人连热身都省了，直接把问题扔给 AI，要它输出一个“像样的起点”。
+
+一旦连起点都不自己造，后面所谓的判断、改写、审核，很多时候也只是在一个别人给你的框架里转。
+
+---
+
+## 二、这不是“AI 让人变笨”那么简单，而是认知卸载开始失控
+
+这件事在认知科学里其实有个更准确的说法，叫 **cognitive offloading**，也就是“认知卸载”。
+
+你把一部分本来要靠大脑完成的任务，交给外部工具来处理。最典型的例子不是 AI，而是：
+
+- 用日历提醒代替记住会议时间
+- 用导航代替记路
+- 用待办清单代替脑内维护任务
+- 用搜索引擎代替长期记忆里的信息提取
+
+从这个角度看，AI 不是突然出现的异类，它只是把“认知卸载”推到了一个新阶段。以前你只是把“记忆”和“检索”外包给工具，现在你开始把：
+
+- 组织表达
+- 初步分析
+- 风险排查
+- 结构搭建
+- 甚至观点生成
+
+也一起外包出去。
+
+问题不在于外包本身。  
+问题在于你有没有在外包之后，保留对任务的掌控权。
+
+一篇关于 intention offloading 的综述提到，外部提醒工具确实非常有效，能显著降低遗忘率；但它同时也提醒我们，认知工具的价值，不等于可以无条件把内部能力彻底让渡出去。[1]
+
+换句话说：
+
+<span class="highlight-text">认知卸载本来是为了腾出脑力做更重要的事，结果很多人却把“更重要的那部分”也一起卸载掉了。</span>
+
+这就是现在很多人对 AI 又依赖又焦虑的原因。
+
+不是因为 AI 真替代了你，而是你越来越不确定：  
+**离开它之后，你还愿不愿意自己想一下。**
+
+---
+
+## 三、真正可怕的体验，不是能力消失，而是“无辅助启动困难”
+
+我觉得原文标题里“terrifying”最有价值的地方，不是制造恐慌，而是准确描述了一种很多人已经出现、但没认真命名过的状态：
+
+**无辅助启动困难。**
+
+什么意思？
+
+不是你不会。  
+是你一旦没有 AI，就明显更难开始。
+
+比如：
+
+- 写文章时，开头迟迟落不下第一句
+- 遇到模糊问题时，不愿意自己先拆
+- 面对复杂任务时，习惯等一个现成框架
+- 明明知道怎么做，但总想先看 AI 给什么版本
+
+这会带来一种很隐蔽的退化。  
+不是知识退化，而是“主动调度自己”的能力在下降。
+
+微软研究院和卡耐基梅隆的研究者在 2025 年一项关于知识工作者的调查里提到：在 GenAI 辅助任务中，**对 AI 越有信心，越倾向于减少批判性思考；而对自己越有信心，越倾向于投入更多批判性思考。**[2]
+
+这句话特别值得细品。
+
+因为它说明一件事：问题不只是工具强不强，而是你在工具面前，把自己摆在什么位置。
+
+如果你默认 AI 是主驾驶，你只是验收员，那久而久之，大脑最常做的工作就会从“建模和推理”变成“浏览和点头”。
+
+这才是我真正担心的地方。
+
+---
+
+## 四、所以要不要少用 AI？
+
+我不觉得答案是“停用 30 天”。
+
+至少对我这种天天跟技术、内容、结构化表达打交道的人来说，完全停用并不现实，也没必要。  
+AI 已经不是一个可有可无的小工具了，它更像是新的工作台。
+
+真正该做的，不是戒掉，而是重新分工。
+
+我现在越来越认可一种更稳的使用方式：
+
+### 1. 第一版思路，尽量自己先起
+
+不管是文章、方案、bug 排查还是项目设计，我会先强迫自己写一个粗糙版本。
+
+哪怕只是：
+
+- 三条判断
+- 一个很丑的提纲
+- 两种可能路径
+- 一段自己都嫌烂的开头
+
+都比“完全空白地问 AI”要好。
+
+因为这一步不是为了产出质量，而是为了保住你作为主导者的上下文。
+
+### 2. 把 AI 用在放大，而不是代替起步
+
+AI 最适合做的是：
+
+- 扩展备选方案
+- 找反例
+- 补结构漏洞
+- 改写表达
+- 做资料归纳
+- 帮你验证
+
+也就是说，它更适合当二号位、陪练、编辑、审稿人、执行器，而不是那个替你先想的人。
+
+### 3. 对高价值任务，坚持自己建模
+
+有些任务可以放心外包，有些不能。
+
+比如“帮我润色一封邮件”，问题不大。  
+但下面这些，我建议一定要自己先建模：
+
+- 重要决策
+- 技术方案取舍
+- 复杂问题归因
+- 价值判断
+- 涉及长期影响的内容表达
+
+因为这些东西里，真正值钱的从来不是字面答案，而是你怎么定义问题、怎么取舍约束、怎么承担后果。
+
+这部分如果长期不练，最后退化的不是写作技巧，而是判断力。
+
+---
+
+## 五、从效率工具到“工具即工作流”，风险已经变了
+
+以前我们讨论工具依赖，通常是在说：
+
+- 没导航就不会走路
+- 没计算器就不想心算
+- 没搜索就懒得记东西
+
+但 AI 带来的变化比这再深一层。
+
+它不只是某个步骤的辅助，而是正在变成一整套工作流入口。
+
+你写作靠它起草。  
+你 coding 靠它补代码。  
+你研究靠它总结。  
+你沟通靠它润色。  
+你做决策前，甚至也想先问一句“你怎么看”。
+
+当工具变成工作流时，依赖的风险就不再只是“少记住一点东西”，而是：
+
+**你越来越少独立经历一整个完整的思考闭环。**
+
+起念、拆题、试错、犹豫、重构、推翻、再建立。  
+这些原本很痛苦，但也正是人真正长能力的地方。
+
+AI 最大的问题，从来不是它太强，而是它太顺了。  
+顺到你很容易误以为自己也完成了同等强度的思考。
+
+其实很多时候，你只是完成了“看起来像思考的交互”。
+
+---
+
+## 六、对工程师来说，最好的姿势不是拒绝 AI，而是把自己放回驾驶位
+
+如果你是程序员、产品、运营、写作者，甚至是管理者，我觉得都可以问自己三个问题：
+
+1. 我现在有哪些任务，已经默认不自己起步了？
+2. 我是把 AI 当副驾，还是当主驾？
+3. 如果今天断网 4 小时，我哪些工作会立刻启动困难？
+
+这三个问题比“AI 会不会让人变笨”更具体。
+
+因为我们真正面对的，不是哲学讨论，而是一个工作习惯正在重构。
+
+我现在越来越倾向于这样理解 AI：
+
+> AI 不是你的外挂大脑，而是你的外部认知基础设施。
+
+基础设施当然重要。  
+但基础设施越重要，你越要知道：**哪些东西该建在外面，哪些东西必须保留在自己身上。**
+
+OpenAI 在讲 harness engineering 的文章里，其实强调的也是类似逻辑：AI 能不能稳定产出，不只是模型问题，更取决于你有没有把环境、验证、约束和反馈机制设计好。[3]
+
+这个思路放到个人层面也一样成立。
+
+如果你不给自己设置边界，AI 就会自然滑向最省力的用法；  
+而最省力的用法，往往不是最能保住你能力的用法。
+
+---
+
+## 最后
+
+我不觉得未来最稀缺的人，是“完全不用 AI 的人”。
+
+那种姿态很快会变成另一种刻意。
+
+我反而觉得，未来更稀缺的人会是下面这类：
+
+- 很会用 AI，但没有把判断力交出去
+- 会借力，但不会失去起步能力
+- 能把 AI 当放大器，而不是当精神代餐
+
+所以看到那篇《停用 ChatGPT 30 天》的文章后，我最后真正记住的，不是“要不要戒掉 AI”，而是另一句话：
+
+<span class="highlight-text">真正的风险不是你用了 AI，而是你越来越少亲自完成那些让自己变强的思考过程。</span>
+
+效率当然重要。  
+但如果效率的代价是，你慢慢失去独立启动、独立判断、独立组织复杂问题的能力，那这个交易就没有看上去那么划算。
+
+AI 最好的位置，从来都不是替你活。  
+它应该替你省力，但不能替你成长。
+
+---
+
+## 参考链接
+
+1. Sam J. Gilbert et al., [Outsourcing Memory to External Tools: A Review of ‘Intention Offloading’](https://link.springer.com/article/10.3758/s13423-022-02139-4)
+2. Hao-Ping Lee et al., Microsoft Research, [The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers](https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/)
+3. OpenAI, [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)
+4. Teja Kusireddy, [I Stopped Using ChatGPT for 30 Days. What Happened to My Brain Was Terrifying.](https://levelup.gitconnected.com/i-stopped-using-chatgpt-for-30-days-what-happened-to-my-brain-was-terrifying-70d2a62246c0)

source/_posts/AI-Harness-Harness-Engineering-AI时代的软件工程核心能力.md

@@ -0,0 +1,664 @@
+---
+title: "AI Harness 深度解析：从概念到工程实践"
+date: 2026-03-18 21:00:00
+author: Gamehu
+tags:
+  - AI
+  - Harness Engineering
+  - LLM Evaluation
+  - 软件工程
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI Infrastructure</span>
+  <span class="sub-tag">续篇</span>
+</div>
+
+上一篇[《从一次 tenantId 联调 bug，看我们该怎么给 AI 项目补齐 harness》](/2026/03/07/从一次tenantId联调bug-看我们该怎么给AI项目补齐harness/)里，我记录了一个真实项目中的 harness 搭建过程。
+
+那次经历让我意识到：
+
+<span class="highlight-text">AI 工程化的竞争力，不是"谁的模型更像天才"，而是"谁先把自己的真实环境整理成一个不会误导 agent 的工作台"。</span>
+
+但「补齐 harness」这件事，说起来容易，做起来却有很多模糊地带——
+
+- Harness 到底包括哪些具体的东西？
+- 什么场景下应该优先补哪部分？
+- 业界那些号称"零手写代码"的项目，他们的 harness 是怎么设计的？
+
+这篇不聊具体 bug 了，我想从**概念、分类、工程实践**三个层面，把 Harness 这件事系统地理清楚。
+
+如果你也在搞 AI Coding，正在困惑"除了写 prompt 还应该做什么"，这篇应该能帮到你。
+
+[^1]: [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/) - OpenAI, 2026-02-11
+
+---
+
+## 什么是 Harness？
+
+**Harness = 用来控制、驱动、约束、评估一个系统行为的外部执行框架**
+
+换句话说：
+- ❌ 不是业务逻辑
+- ✅ 是"包在系统外面的一层控制系统"
+
+### 类比理解
+
+| 类比 | 含义 |
+|------|------|
+| 马具（Horse Harness） | 控制马的方向和行为 |
+| 安全带 | 限制人的自由，保证安全 |
+| Test Harness | 控制程序执行并验证结果 |
+
+核心本质：**让一个"有能力但不可控"的系统变得可控**。[^2]
+
+[^2]: [Test harness - Wikipedia](https://en.wikipedia.org/wiki/Test_harness)
+
+---
+
+## 传统软件中的 Harness（你其实一直在用）
+
+在 AI 火爆之前，Harness 这个概念已经在软件工程中存在几十年了。你可能每天都在用，只是没意识到。
+
+### 1. Test Harness（测试框架）——最经典
+
+这是 Harness 一词在软件工程中最常见的用法。
+
+```
+被测系统（SUT） ←→ Test Harness
+                ↑
+        ┌───────┴───────┐
+        │  - 输入构造    │
+        │  - Mock/Stub   │
+        │  - 执行控制    │
+        │  - 输出验证    │
+        │  - 日志收集    │
+        └───────────────┘
+```
+
+**实际例子**：
+- JUnit / TestNG 测试框架
+- 集成测试时启动的嵌入式数据库（H2）
+- 模拟外部 API 的 WireMock / MockServer
+
+### 2. Benchmark Harness（基准测试框架）
+
+Java 开发者最熟悉的 **JMH**（Java Microbenchmark Harness）就是典型代表。[^3]
+
+[^3]: [JMH - OpenJDK](https://openjdk.org/projects/code-tools/jmh/)
+
+```java
+@BenchmarkMode(Mode.AverageTime)
+@OutputTimeUnit(TimeUnit.MILLISECONDS)
+public class MyBenchmark {
+    @Benchmark
+    public void testMethod() {
+        // 被测代码
+    }
+}
+```
+
+**Harness 的作用**：
+- 预热 JVM，消除 JIT 编译影响
+- 多轮运行，统计置信区间
+- 控制 GC 时机，减少干扰
+- 输出标准化的性能报告
+
+### 3. Integration Harness（集成测试框架）
+
+日常开发中常用的：
+
+```yaml
+# 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 系统
+
+| 维度 | 传统软件 | AI 系统 |
+|------|----------|---------|
+| 行为决定 | 代码决定 | Prompt + Model + Context |
+| 确定性 | 确定性 | 概率性 |
+| 断言方式 | `assertEquals(expected, actual)` | 自然语言输出（无限空间） |
+| 可预测性 | 同一输入永远同一输出 | 同一 Prompt 可能不同结果 |
+
+同一个 Prompt：
+- 第一次正确
+- 第二次错误
+- 第三次又正确
+
+这就是 AI 开发的日常。
+
+---
+
+## 从 Prompt Engineering 到 Harness Engineering
+
+### 阶段一：Prompt Engineering（2023-2024）
+
+关注点是"我怎么写 prompt 更聪明"。
+
+```
+给定角色 + 分步骤 + 加示例 → 期望输出
+```
+
+### 阶段二：Context Engineering（2025）
+
+Andrej Karpathy 在 2025 年的推文中强调：**"context engineering > prompt engineering"**。[^4]
+
+关注点是"模型在推理时能看到什么完整上下文"。
+
+```
+RAG + MCP + Memory + 外部工具 → 丰富上下文
+```
+
+[^4]: [Andrej Karpathy on X](https://x.com/karpathy/status/1937902205765607626) - 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](https://mitchellh.com/writing/my-ai-adoption-journey) - 2026-02
+
+---
+
+## AI Harness 的核心定义
+
+> **AI Harness = 用于系统性验证、评估、对比、约束 LLM 行为的工程基础设施**
+
+### 架构组成
+
+```
+┌──────────────────────┐
+│     Test Dataset     │  ← 测试数据集（Prompt + Context）
+│ (Prompt + Context)   │
+└─────────┬────────────┘
+          ↓
+┌──────────────────────┐
+│      Harness         │  ← 执行框架
+│                      │
+│ - 调用模型           │
+│ - 控制参数           │
+│ - 重试策略           │
+│ - 日志记录           │
+└─────────┬────────────┘
+          ↓
+┌──────────────────────┐
+│     Evaluator        │  ← 评估器（规则 / LLM评估）
+│ (规则 / LLM评估)     │
+└─────────┬────────────┘
+          ↓
+┌──────────────────────┐
+│      Metrics         │  ← 指标（准确率 / 稳定性 / 延迟）
+│ (accuracy / score)   │
+└──────────────────────┘
+```
+
+---
+
+## 真实案例：没有 Harness vs 有 Harness
+
+### 场景：客户对话意图识别
+
+输入：客户说"这个太贵了"  
+期望输出：`{"intent": "价格异议"}`
+
+#### ❌ 没有 Harness
+
+- 手动调 Prompt
+- 靠感觉判断效果
+- 不可复现
+
+👉 玄学开发
+
+#### ✅ 有 Harness
+
+**Step 1：构建测试集**
+
+```json
+[
+  {
+    "id": "case_001",
+    "input": "客户说：这个太贵了",
+    "expected": {"intent": "价格异议"}
+  },
+  {
+    "id": "case_002", 
+    "input": "能便宜点吗",
+    "expected": {"intent": "价格异议"}
+  }
+]
+```
+
+**Step 2：执行 Harness**
+
+- 调用 LLM
+- 控制 temperature
+- 多次运行取平均
+
+**Step 3：评估**
+
+```python
+# 规则评估
+assert actual.intent == expected.intent
+
+# 或用 LLM 评估（LLM-as-a-Judge）
+judge_prompt = f"""
+评估以下输出是否正确：
+输入：{input}
+期望：{expected}
+实际：{actual}
+返回：正确/错误 + 原因
+"""
+```
+
+**Step 4：输出指标**
+
+```
+accuracy = 87%
+stability = 方差 < 5%
+avg_latency = 450ms
+```
+
+👉 **本质：把 AI 从"感觉好不好"变成"指标好不好"**[^6]
+
+[^6]: [LLM Testing Framework Guide](https://www.leanware.co/insights/llm-testing-framework-guide) - Leanware, 2025-11-13
+
+---
+
+## OpenAI 的实验数据
+
+OpenAI 在 2025 年 8 月-2026 年 1 月进行了一项实验：[^1]
+
+| 指标 | 数据 |
+|------|------|
+| 团队规模 | 3 → 7 人 |
+| 手写代码 | 0 行 |
+| 生成代码 | 约 100 万行 |
+| Pull Request | 约 1500 个 |
+| 平均 PR/天 | 3.5 个/工程师 |
+| 速度估算 | 比手动开发快约 10 倍 |
+
+关键点：**初期生产力很低**，因为环境、工具、抽象和 repo 内部结构尚未充分为 agent 优化。随着 Harness 逐步完善，性能才大幅提升。
+
+工程师的角色变成了"让智能体有用"——设计系统、架构和约束条件。
+
+---
+
+## Harness 改变结果的惊人案例
+
+### 案例 1：Hashline（Can Boluk, 2026）
+
+安全研究员 Can Boluk 发布了一个实验，只改变智能体的编辑格式：[^5]
+
+```
+# 传统格式
+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](https://aiengineerlab.in/models/evaluation/) - AI Engineer Lab, 2026-03-13
+[^8]: [LLM Evaluation Framework](https://www.getzep.com/ai-agents/llm-evaluation-framework/) - Zep AI, 2025-03-01
+[^11]: [Anthropic - Building a C compiler with a team of parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler)
+[^12]: [Vercel - We removed 80% of our agent's tools](https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools)
+
+### 0. 可读环境（Legible Environment）—— 长时任务的基础
+
+对于长时运行的智能体，最重要但最容易被忽视的是**环境可读性**。
+
+当一个新的 Agent 会话"接手"任务时，它需要在几分钟内理解：
+- 项目当前状态是什么？
+- 已经完成了什么？
+- 下一步要做什么？
+
+**最佳实践**：
+
+| 文件 | 用途 |
+|------|------|
+| `features.json` | 功能清单和完成状态 |
+| `progress.md` | 当前进度和阻塞项 |
+| `AGENTS.md` | 项目架构和开发规范 |
+| `init.sh` | 环境初始化脚本 |
+| Git 提交历史 | 变更记录和决策轨迹 |
+
+**关键原则**：
+> 每个会话应该能快速"读懂"项目，而不是靠猜测或试错。
+
+Vercel 和 Anthropic 的实践表明：**结构化的进度跟踪文件比复杂的记忆系统更有效**。[^11]
+
+### 1. Test Case 管理
+
+```json
+{
+  "id": "case_001",
+  "input": "...",
+  "expected": {...},
+  "metadata": {
+    "category": "价格异议",
+    "difficulty": "medium",
+    "source": "production_log"
+  }
+}
+```
+
+### 2. 执行器（Executor）
+
+- 支持多模型（GPT / Claude / DeepSeek / Qwen）
+- 支持多 Prompt 版本
+- 控制温度、重试策略
+
+### 3. Evaluator（评估器）
+
+| 评估方式 | 适用场景 |
+|----------|----------|
+| **规则匹配** | JSON 结构验证、正则匹配 |
+| **LLM-as-a-Judge** | 主观质量、语义相似度 |
+| **人工评审** | 复杂场景、边界 case |
+| **混合评估** | 先用规则过滤，再用 LLM 评估 |
+
+### 4. Metrics（指标）
+
+- **accuracy**：意图识别准确率
+- **faithfulness**：事实一致性（防幻觉）
+- **stability**：多次运行方差
+- **latency**：响应延迟
+- **cost**：单次调用成本
+- **format_reliability**：结构化输出成功率
+
+### 5. E2E 验证（端到端测试）—— 防止"假完成"
+
+**关键洞察**：Agent 有强烈的倾向过早声明任务"完成"。这一观察来自多个团队的自主 agent 实验总结。
+
+单元测试不够，因为 Agent 可能：
+- 代码通过了测试，但功能不工作
+- 实现了功能，但引入了回归 bug
+- 完成了任务，但破坏了其他模块
+
+**解决方案**：提供端到端验证工具
+
+| 场景 | 验证工具 |
+|------|----------|
+| Web 应用 | Puppeteer、Playwright |
+| API 服务 | 自动化集成测试 |
+| 数据处理 | 输出数据校验 |
+| 代码生成 | 编译 + 运行测试 |
+
+**反馈循环**：
+```
+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 集成
+
+```
+git push →
+自动跑 harness →
+指标下降 → 阻断发布
+```
+
+[^9]: [DeepEval - LLM Evaluation Framework](https://github.com/confident-ai/deepeval)
+
+---
+
+## 可用的 Harness 工具生态
+
+### 开源框架
+
+| 工具 | 特点 | 链接 |
+|------|------|------|
+| **OpenAI Evals** | 官方评估框架 | [github.com/openai/evals](https://github.com/openai/evals) |
+| **DeepEval** | Pytest 风格，14+ 内置指标 | [github.com/confident-ai/deepeval](https://github.com/confident-ai/deepeval) |
+| **Promptfoo** | Prompt 测试和模型对比 | [github.com/promptfoo/promptfoo](https://github.com/promptfoo/promptfoo) |
+| **HELM** | Stanford 的 holistic 评估 | [crfm.stanford.edu/helm](https://crfm.stanford.edu/helm/latest/) |
+| **LangSmith** | LangChain 生态的观测和评估 | [smith.langchain.com](https://smith.langchain.com) |
+| **Ragas** | RAG 管道评估标准 | [github.com/explodinggradients/ragas](https://github.com/explodinggradients/ragas) |
+
+### 商业平台
+
+| 平台 | 特点 |
+|------|------|
+| **Galileo** | 企业级，内置 guardrails 和实时监控 |
+| **Arize Phoenix** | 开源可观测性 + 幻觉检测 |
+| **Weights & Biases** | 实验跟踪 + LLM 评估 |
+
+---
+
+## 工程落地建议
+
+### 起步三要素
+
+1. **写上下文文件**
+   
+   创建 `CLAUDE.md` 或 `AGENTS.md`，包含：
+   - 项目结构
+   - 构建命令
+   - 编码规范
+   
+   每次智能体犯错，就添加一条防止再犯的规则。[^5]
+
+2. **选择性地连接 MCP**
+   
+   如果智能体经常引用某个外部系统，就通过 MCP 连接它。典型例子包括 Issue Tracker、Wiki、监控系统。
+   
+   **但只连接必要的**，否则 token 会被浪费。
+
+3. **从简单评估开始**
+   
+   - 收集 50 个真实生产 Prompt
+   - 在 3-5 个模型上运行
+   - 人工评分，对比差异
+   - 逐步自动化
+
+### 常见陷阱
+
+| 陷阱 | 解决方式 |
+|------|----------|
+| 只用合成数据 | 必须包含真实生产案例 |
+| 测试样本太少 | 至少 30-50 个例子 |
+| 忽略延迟和成本 | 把速度和价格纳入评估 |
+| 过早过度自动化 | 早期保留人工评审 |
+| 只关注模型能力 | 测试完整系统，不只是模型输出 |
+
+---
+
+## 核心总结
+
+> **Harness 的本质：让不可控系统变成可度量、可优化、可上线的工程系统**
+
+AI 开发的核心资产正在转移：
+
+| 过去 | 现在 |
+|------|------|
+| 代码 | 数据集 |
+| 逻辑 | Prompt |
+| 单测 | Harness |
+
+如果用传统软件工程类比，Harness Engineering 有点像 JUnit、CI/CD、测试基建、脚手架、约束机制和运行环境设计的组合体——它覆盖的不只是"评测和 CI"，还包括 agent legibility、repo as system of record、AGENTS.md、自动化反馈循环、工具约束、任务接力、E2E verification、并行协作结构。
+
+你写的 Prompt、RAG 流程、Agent 逻辑——这些都需要被评估、被约束、被持续监控。
+
+---
+
+## 参考资源
+
+### 官方/论文
+
+- [OpenAI Harness Engineering](https://openai.com/index/harness-engineering/) - OpenAI 官方文章
+- [OpenAI Evals](https://github.com/openai/evals) - 官方评估框架
+- [HELM - Stanford](https://crfm.stanford.edu/helm/latest/) - 全面的 LLM 评估基准
+- [Test Harness - Wikipedia](https://en.wikipedia.org/wiki/Test_harness)
+
+### 工程实践
+
+- [Promptfoo](https://github.com/promptfoo/promptfoo) - 开源 Prompt 测试框架
+- [DeepEval](https://github.com/confident-ai/deepeval) - Python LLM 评估框架
+- [LangChain Evaluation](https://python.langchain.com/docs/guides/evaluation/) - LangChain 评估指南
+
+### 深度解读
+
+- [Beyond Prompts and Context: Harness Engineering](https://madplay.github.io/en/post/harness-engineering) - 概念演进时间线
+- [OpenAI Harness Engineering - InfoQ](https://www.infoq.com/news/2026/02/openai-harness-engineering-codex/) - 中文技术解读
+- [LLM Testing Framework Guide](https://www.leanware.co/insights/llm-testing-framework-guide) - 测试框架最佳实践
+- [How to Evaluate LLMs](https://aiengineerlab.in/models/evaluation/) - 实用评估方法
+
+### 官方工程博客
+
+- [OpenAI - Harness engineering](https://openai.com/index/harness-engineering/) - OpenAI 官方 Harness Engineering 文章
+- [Anthropic - Building a C compiler with parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler) - Anthropic 并行 agent 实验
+- [Cursor - Scaling long-running autonomous coding](https://cursor.com/blog/scaling-agents) - Cursor 长时自主编码实验
+- [Vercel - We removed 80% of our agent's tools](https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools) - Vercel 工具设计经验
+- [Mitchell Hashimoto - My AI Adoption Journey](https://mitchellh.com/writing/my-ai-adoption-journey) - Harness Engineering 概念提出
+
+### 视频
+
+- [Andrej Karpathy - Software 2.0](https://www.youtube.com/watch?v=zjkBMFhNj_g) - 关于 AI 软件范式的经典演讲
+
+---
+
+## 最后
+
+我们正处在一个转折点。
+
+Prompt Engineering 只是开始，Context Engineering 是中间阶段，而 **Harness Engineering** 是 AI 应用走向生产就绪的必经之路。
+
+如果你正在开发 AI 应用，不妨从今天开始：
+
+1. 收集 50 个真实的测试用例
+2. 建立一个简单的评估脚本
+3. 在每次 Prompt 变更时跑一遍
+
+这就是 Harness 的起点。

source/_posts/Claude-Code-Skills-最佳实践-Anthropic内部经验分享.md

@@ -0,0 +1,222 @@
+---
+title: Claude Code 中的 Skills：Anthropic 内部使用经验与最佳实践
+date: 2026-03-18 20:30:00
+author: Gamehu
+tags:
+  - AI
+  - Claude Code
+  - Skills
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI 工具</span>
+</div>
+
+前几天在 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 助手越用越顺手。
+
+---
+
+**参考链接**：
+- [原文推文](https://x.com/trq212/status/2033949937936085378) - @trq212
+- [Skilljar 课程](https://skilljar.com) - 《Agent Skills》入门课程
+- [Claude Code 文档](https://docs.anthropic.com/en/docs/claude-code/skills)

source/_posts/Claude-Code多智能体编排实战-wshobson-agents深度解析.md

@@ -19,7 +19,7 @@ categories:
 
 ## 缘起
 
-前段时间写了 OpenClaw 那篇文章，讲怎么用编排层管理多个 AI 代理。最近发现一个 GitHub 项目 <span class="highlight-text">wshobson/agents</span>，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。
+最近发现一个 GitHub 项目 <span class="highlight-text">wshobson/agents</span>，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。
 
 让我震撼的几个数字：
 

source/_posts/why-people-hate-ai-more-than-ice/cover.svg

@@ -0,0 +1,60 @@
+<svg width="1600" height="900" viewBox="0 0 1600 900" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <defs>
+    <linearGradient id="bg" x1="90" y1="60" x2="1470" y2="860" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#F6F1E8"/>
+      <stop offset="1" stop-color="#DDD4C7"/>
+    </linearGradient>
+    <linearGradient id="redGlow" x1="1130" y1="140" x2="1490" y2="520" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#FF5E4D"/>
+      <stop offset="1" stop-color="#B61D14"/>
+    </linearGradient>
+    <linearGradient id="blackFade" x1="390" y1="320" x2="1080" y2="760" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#131313"/>
+      <stop offset="1" stop-color="#272727"/>
+    </linearGradient>
+    <filter id="shadow" x="0" y="0" width="1600" height="900" filterUnits="userSpaceOnUse" color-interpolation-filters="sRGB">
+      <feDropShadow dx="0" dy="18" stdDeviation="24" flood-color="#000000" flood-opacity="0.18"/>
+    </filter>
+  </defs>
+
+  <rect width="1600" height="900" fill="url(#bg)"/>
+  <rect x="0" y="0" width="1600" height="900" fill="#000000" fill-opacity="0.04"/>
+
+  <g opacity="0.18">
+    <path d="M0 178H1600" stroke="#1B1B1B" stroke-width="2" stroke-dasharray="10 18"/>
+    <path d="M0 618H1600" stroke="#1B1B1B" stroke-width="2" stroke-dasharray="10 18"/>
+    <path d="M228 0V900" stroke="#1B1B1B" stroke-width="2" stroke-dasharray="10 18"/>
+    <path d="M1276 0V900" stroke="#1B1B1B" stroke-width="2" stroke-dasharray="10 18"/>
+  </g>
+
+  <rect x="1068" y="106" width="394" height="394" rx="32" transform="rotate(8 1068 106)" fill="url(#redGlow)" opacity="0.96"/>
+  <rect x="1006" y="506" width="482" height="76" rx="12" fill="#C4271A"/>
+  <rect x="1054" y="536" width="380" height="12" rx="6" fill="#F6F1E8" fill-opacity="0.45"/>
+
+  <g filter="url(#shadow)">
+    <path d="M382 260C382 231.281 405.281 208 434 208H1018C1046.72 208 1070 231.281 1070 260V576C1070 604.719 1046.72 628 1018 628H604L492 716V628H434C405.281 628 382 604.719 382 576V260Z" fill="url(#blackFade)"/>
+    <rect x="420" y="248" width="612" height="342" rx="26" fill="#191919"/>
+  </g>
+
+  <text x="470" y="430" fill="#F7F0E4" font-size="226" font-weight="900" font-family="'Arial Black', 'Noto Sans SC', sans-serif">46%</text>
+  <text x="468" y="504" fill="#FF5E4D" font-size="40" font-weight="800" font-family="'Arial Black', 'Noto Sans SC', sans-serif" letter-spacing="6">NEGATIVE</text>
+
+  <text x="1112" y="268" fill="#F7F0E4" font-size="150" font-weight="900" font-family="'Arial Black', 'Noto Sans SC', sans-serif">AI</text>
+  <text x="1116" y="334" fill="#1D1D1D" font-size="40" font-weight="900" font-family="'Arial Black', 'Noto Sans SC', sans-serif" letter-spacing="10">PUBLIC MOOD</text>
+
+  <g opacity="0.85">
+    <rect x="104" y="114" width="244" height="50" rx="25" fill="#1D1D1D"/>
+    <text x="132" y="147" fill="#F7F0E4" font-size="24" font-weight="700" font-family="'Arial Black', 'Noto Sans SC', sans-serif" letter-spacing="2">REDDIT SIGNAL</text>
+  </g>
+
+  <g opacity="0.16">
+    <path d="M1178 664C1178 646.327 1192.33 632 1210 632H1430C1447.67 632 1462 646.327 1462 664V730C1462 747.673 1447.67 762 1430 762H1272L1228 796V762H1210C1192.33 762 1178 747.673 1178 730V664Z" fill="#1D1D1D"/>
+    <path d="M131 720C131 704.536 143.536 692 159 692H333C348.464 692 361 704.536 361 720V780C361 795.464 348.464 808 333 808H215L178 838V808H159C143.536 808 131 795.464 131 780V720Z" fill="#1D1D1D"/>
+  </g>
+
+  <text x="104" y="760" fill="#1D1D1D" font-size="58" font-weight="900" font-family="'Arial Black', 'Noto Sans SC', sans-serif">当 AI 比 ICE 还招人恨</text>
+  <text x="106" y="820" fill="#4B4741" font-size="28" font-weight="700" font-family="'Arial Black', 'Noto Sans SC', sans-serif" letter-spacing="3">我们到底在恐惧什么？</text>
+
+  <rect x="104" y="84" width="264" height="6" fill="#C4271A"/>
+  <rect x="104" y="840" width="512" height="8" fill="#C4271A"/>
+</svg>

source/_posts/「动话」产品深度解析：用「丑萌换头」打造低成本-viral-社交产品.md

@@ -1,254 +0,0 @@
----
-title: 「动话」产品深度解析：用「丑萌换头」打造低成本 viral 社交产品
-author: Gamehu
-date: 2026-03-12 12:36:42
-categories:
-  - 产品
-tags:
-  - 产品设计
-  - AI
-  - 社交产品
-  - 创业
----
-
-# 「动话」产品深度解析：用「丑萌换头」打造下一个 viral 社交产品
-
-> 一句话总结：把 AI 动画生成的成本从 ¥0.5/次降到 ¥0.001/次，速度从 60 秒提升到 3 秒，同时让每个人都成为动画主角。
-
----
-
-## 一、产品定位
-
-**一句话定义**：
-抖音版的「丑萌换头动画」—— 你的头，我的动画，3 秒出片。
-
-**核心价值**：
-- **零门槛**：不需要任何动画基础，上传头像就能做动画
-- **即时满足**：3 秒出片，比拍照还快
-- **社交货币**：生成的内容自带「这是我」标签，激发分享欲
-
----
-
-## 二、核心洞察：为什么要做「丑萌」+「换头」
-
-### 2.1 市场现状的问题
-
-当前 AI 动画产品（如 Runway、Pika、可灵）都在追求「精美」，但带来了三个致命问题：
-
-| 问题 | 后果 |
-|------|------|
-| 生成成本高（¥0.5-2/次）| 无法规模化 |
-| 生成时间长（30-60 秒）| 用户流失 |
-| 效果不稳定（容易翻车）| 体验不可控 |
-
-### 2.2 「丑萌」的机会
-
-**什么是丑萌**：
-- 不追求精美，追求「魔性」和「上头」
-- 简单线条、夸张表情、鬼畜动作
-- 参考：Line Friends、小矛动物园、可达鸭
-
-**为什么丑萌能火**：
-1. **降低预期**：用户不会因为「不够精美」而失望
-2. **喜剧效果**：丑到极致反而产生萌感
-3. **病毒传播**：魔性内容天然适合分享
-4. **成本极低**：简单几何形状拼接，无需精细渲染
-
-### 2.3 「换头」的社交属性
-
-**不是「生成你的卡通形象」**，而是「把你的头安到动画角色上」：
-
-```
-原始动画角色    用户上传头像     换头后效果
-┌─────────┐   ┌─────────┐   ┌─────────┐
-│  🤖     │   │  👤     │   │  👤     │
-│  /|\    │ + │  /|\    │ = │  /|\    │
-│  / \    │   │         │   │  / \    │
-└─────────┘   └─────────┘   └─────────┘
-  丑萌身体        真实头像      魔性组合
-```
-
-**换头的化学反应**：
-- 真实头像 + 丑萌身体 = **违和感 = 喜剧效果**
-- 「这是我」的代入感，激发分享欲
-- 恶搞好友、追星二创、职场吐槽，场景丰富
-
----
-
-## 三、产品功能设计
-
-### 3.1 核心流程：3 步出片
-
-```
-Step 1: 选场景
-├── 热门场景：跳海草舞、加班崩溃、表白成功、健身达人
-└── 分类：搞笑 / 吐槽 / 表白 / 日常 / 节日
-
-Step 2: 换头（可选）
-├── 拍照 / 相册 / 表情包
-├── 支持多人：添加好友的头
-└── 实时预览换头效果
-
-Step 3: 配文案（可选）→ 生成
-```
-
-**极简路径**：选场景 → 点生成 → 完成（3 秒）
-**进阶路径**：选场景 → 换头 → 配文案 → 生成（10 秒）
-
-### 3.2 场景库设计
-
-**预渲染模板模式**（非 AI 实时生成）：
-
-| 场景类型 | 示例 | 特点 |
-|---------|------|------|
-| 搞笑类 | 海草舞、鸡你太美、科目三 | 魔性重复动作 |
-| 吐槽类 | 加班崩溃、早起困难、周一综合征 | 夸张表情+慢动作 |
-| 表白类 | 比心、跪地求婚、壁咚 | 浪漫 BGM+定格 |
-| 日常类 | 干饭、睡觉、摸鱼 | 循环播放 |
-| 节日类 | 生日祝福、新年快乐 | 应景道具+特效 |
-
-**每个模板**：
-- 预渲染好的动画（5-10 秒）
-- 头部区域已标记，支持替换
-- 支持换色、变速、配乐
-
-### 3.3 社交玩法
-
-**玩法 1：换头挑战**
-- 官方发起：「#用老板的头跳科目三」
-- 用户上传老板/好友/明星头像
-- 点赞最高者获得奖励
-
-**玩法 2：双人换头**
-- 支持两个头像替换
-- 场景：「我和闺蜜跳女团舞」「我和老板角色互换」
-
-**玩法 3：接龙换头**
-- 用户 A 发海草舞（小明的头）
-- 用户 B 接力：同一支舞，换小红的头
-- 形成「海草舞接龙」话题
-
----
-
-## 四、技术方案：极致低成本
-
-### 4.1 核心架构
-
-```
-预渲染模板（视频文件）
-      ↓
-用户上传头像
-      ↓
-人脸检测 + 裁剪 + 贴合（OpenCV，CPU 实时）
-      ↓
-导出视频（<1 秒）
-```
-
-**没有 GPU！没有 AI 生成！**
-
-### 4.2 成本对比
-
-| 方案 | 单次成本 | 生成时间 | 稳定性 |
-|------|---------|---------|--------|
-| AI 实时生成（Runway） | ¥0.5-2 | 30-60 秒 | 易翻车 |
-| AI 本地部署（AnimateDiff） | ¥0.01 | 20-30 秒 | 中等 |
-| **预渲染+换头（动话）** | **¥0.001** | **<1 秒** | **100%** |
-
-### 4.3 月度运营成本
-
-| 项目 | 成本 | 说明 |
-|------|------|------|
-| OSS 存储 | ¥50 | 100GB 模板+用户作品 |
-| OSS 流量 | ¥100 | 约 1TB/月 |
-| 云服务器 | ¥200 | 2 核 4G 足够 |
-| CDN | ¥0 | Cloudflare 免费 |
-| 数据库 | ¥0 | Supabase 免费版 |
-| **总计** | **¥350/月** | 可支持 1 万日活 |
-
-**单次使用成本：约 ¥0.002**
-
----
-
-## 五、商业模式
-
-### 5.1 免费 vs 付费
-
-| 功能 | 免费用户 | 付费用户（¥9.9/月）|
-|------|---------|------------------|
-| 每日生成次数 | 5 次 | 无限 |
-| 视频分辨率 | 720p | 1080p |
-| 专属模板 | 基础 | 高级+节日限定 |
-| 多人换头 | 2 人 | 无限 |
-| 水印 | 有 | 无 |
-
-### 5.2 创作者分成
-
-- 模板被使用：创作者获得分成
-- 接龙故事被采用：参与者分成
-- 爆款作品打赏：平台抽成 30%
-
----
-
-## 六、竞品差异化
-
-| 产品 | 模式 | 成本 | 门槛 | 动话优势 |
-|------|------|------|------|---------|
-| 剪映 | 手动剪辑 | 时间成本高 | 中 | 一键生成 |
-| 可灵 AI | AI 生成 | ¥0.5/次 | 需构思 prompt | 零成本+选模板 |
-| 妙鸭相机 | AI 写真 | ¥9.9/套 | 需等待 | 即时出片+视频 |
-| FacePlay | 换脸视频 | 订阅制 | 模板固定 | 丑萌风格+UGC 场景 |
-
-**核心差异**：
-- 比 AI 生成**快 100 倍**（3 秒 vs 60 秒）
-- 比手动剪辑**简单 100 倍**（一键 vs 半小时）
-- 成本比 AI 生成**低 1000 倍**（¥0.001 vs ¥0.5）
-
----
-
-## 七、产品路线图
-
-### Phase 1：MVP（1 个月）
-- [ ] 20 个丑萌动画模板
-- [ ] 基础换头功能
-- [ ] 分享到微信/抖音
-- **目标**：验证「换头+丑萌」是否有人愿意玩
-
-### Phase 2：社交（2 个月）
-- [ ] 换头挑战功能
-- [ ] 双人换头
-- [ ] 评论区互动
-- **目标**：验证社交传播能力
-
-### Phase 3：生态（3 个月）
-- [ ] 用户投稿模板
-- [ ] 模板市场
-- [ ] 创作者分成
-- **目标**：建立 UGC 飞轮
-
----
-
-## 八、关键成功指标
-
-| 指标 | 目标值 |
-|------|--------|
-| 次日留存 | >40% |
-| 分享率 | >30% |
-| 单次使用成本 | <¥0.01 |
-| 生成成功率 | >99% |
-| 付费转化率 | >5% |
-
----
-
-## 九、总结
-
-「动话」的核心不是技术，而是**产品定义的创新**：
-
-1. **放弃「精美」追求「丑萌」**：降低预期，提升传播性
-2. **放弃「AI 生成」追求「预渲染+换头」**：降低成本，提升速度
-3. **强化「社交货币」属性**：让每个人都成为动画主角
-
-这个产品的爆点在于：**让普通人也能做出「看起来花了很大功夫」的动画内容**，满足创作欲和分享欲，同时成本极低、速度极快、效果可控。
-
----
-
-*本文基于实际产品调研和技术方案分析整理而成。*

source/_posts/多元思维模型-别急着加人.md

@@ -0,0 +1,250 @@
+---
+title: 老板老问工期能不能再快点，怎么聊
+date: 2026-03-11 20:00:00
+author: Gamehu
+tags:
+  - 思维模型
+  - 团队管理
+  - 查理·芒格
+categories:
+  - 技术管理
+---
+
+> 最近输出有点频繁，主要是这几天项目没那么满，再加上龙虾每天都在逼我成长，老跟我聊各种话题。
+>
+> 今天刚好聊到一个很典型的管理问题：老板觉得工期慢，或者会追着问一句“这个时间还能不能再快点？”后来回头看，这事儿还真不是一个维度能说清的。
+
+这事我是真踩过坑。
+
+前阵子带团队做项目，老板很着急，想尽快把产品推出来。这个诉求本身没毛病，谁做项目不想快一点呢。
+
+问题是，每次汇报进度，他都觉得还是慢，或者会继续追问一句：
+
+**“这个时间有没有办法再压一压？”**
+
+这句话听起来很普通，但真落到团队身上，杀伤力其实不小。
+
+因为它后面往往会带出一连串动作：要不要加人，要不要并行，要不要砍流程，要不要先糙一点上线。
+
+我后来回头看，问题根本不是一句“人不够”能解释的，甚至很多时候，核心矛盾都不是“要不要加人”。
+
+真正的问题是：**老板觉得慢，到底是真的慢，还是大家看问题的角度不一样？**
+
+如果硬套芒格那句老话，就是：**别一上来就拿一个动作当答案。**
+
+---
+
+## 单一思维最容易把人带沟里
+
+工程师和老板在这件事上，其实都很容易掉进同一个坑：
+
+- 进度慢
+- 开始着急
+- 立刻想办法压工期
+- 先上动作，再看问题
+
+逻辑听起来很顺，但现实里经常不成立。
+
+因为软件研发不是搬砖。你以为自己在压时间，实际可能只是把复杂度、返工和沟通成本往后推。
+
+所以这类问题，如果只用一个视角看，很容易越搞越乱。你得换几个角度一起看，才比较接近真相。
+
+下面这几个角度，是我后来觉得最有用的。
+
+---
+
+## 五个视角，拆开看这件事
+
+### 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）](https://book.douban.com/subject/3550167/)** - 彼得·考夫曼（Peter D. Kaufman）编，2005 年
+- **查理·芒格 1994 年南加州大学商学院演讲** - [《论基本普世智慧及其与投资与商业的关系》](https://www.jianshu.com/p/8b5c7b2b615a)
+- **[《人月神话》（The Mythical Man-Month）](https://book.douban.com/subject/1102259/)** - 弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）著，1975 年
+- **[《目标》（The Goal）](https://book.douban.com/subject/25847387/)** - 埃利亚胡·高德拉特（Eliyahu M. Goldratt）著，1984 年
+- **丹尼尔·卡尼曼（Daniel Kahneman）** - [损失厌恶（Loss Aversion）](https://en.wikipedia.org/wiki/Loss_aversion) 理论