Posts

来源：「厂内 AI 实践学习档案」2026-04-19 ～ 2026-05-11 | 30+ 篇实践案例提炼 整理人：hongxinbo | 整理时间：2026-05-11 一、最高频共识：AI 质量上限定律 AI 生成的质量上限 = 人的规约/设计文档的质量上限，与模型能力无关。 这是出现频率最高（8+ 次）的核心结论，被以下实践反复印证： Spec-Driven 四层规约：「两天两万行代码只出一个 bug」的底层密码 Design Token：有 Token，AI Demo 还原度 20% → 90%+ 0 行手写代码反而要求更多深度思考 NMLeak、OOM 排查：Plan 模式前置 = 结构化对齐 > 直接生成 Superpowers 强制澄清流程：纪律 > 智力 实操结论：每个功能开始前花几百字写清楚——问题背景、边界条件、验收标准、不做什么。前置思考 1 分钟，节省后期 10 倍返工时间。 二、Spec-Driven 规约体系（四层） 适用场景：长期项目、核心系统、多人协作 架构层（Architecture） ↓ 服务边界、数据流向、技术选型 契约层（Contract） ↓ 接口定义、数据结构、依赖关系 具体规格层（Specification） ↓ 每个功能的行为描述、边界条件、异常处理 Story 交付清单（Stories） ↓ 可验证的最小交付单元，含验收标准 核心价值：把脑子里的隐含假设显性化为可执行规约，人定义边界、AI 填充实现。 「反向采访」技术：把问题+背景+架构给 AI，让它以架构师角色主动向你提问，把隐含假设全挖出来——比直接命令 AI 更有效。 三、Vibe Coding vs Spec Coding 的适用边界 维度 Vibe Coding Spec Coding 适用场景 短期/小功能/快速验证/Demo 长期/核心系统/多人协作/生产级 前置投入 低 高（方案和 Spec 前置近 4 天） 输出质量 不稳定 「两天两万行代码只出 1 个 bug」 返工风险 高（数据库设计/接口划分等架构决策一旦 Vibe 进去需完全重做） 低 PM 边界 PM Vibe 1 天做 Demo，RD 花 1 周重构核心 PM 定义 WHAT，AI 负责 HOW 关键洞察：速度感是假象，架构判断才是 PM 真正不可让渡的核心价值。 ...

来源：《Learn Harness Engineering》sanbuphy 著（共127页）| 整理时间：2026-05-11 核心结论：Agent 效果不好，不一定是模型的问题，很可能是你的 Harness 不够好。 一、核心概念：什么是 Harness Engineering？ 关键公式 Agent = Model + Harness Harness = 模型权重之外的一切工程基础设施，包括： 指令文件（AGENTS.md / CLAUDE.md） 工具访问权限 运行环境配置 状态持久化机制 验证与反馈回路 三次范式迁移 年份 范式 核心问题 2023 Prompt Engineering 如何跟模型说话 2024-25 Context Engineering 给模型看什么 2026 Harness Engineering 如何让 Agent 在真实世界持续可靠地工作 反直觉前提 同一个模型（Opus 4.5），同一段提示词（“做一个 2D 复古游戏编辑器”）： 裸跑：20分钟，花 $9，游戏核心功能跑不起来 配上完整 Harness（planner + generator + evaluator）：6小时，花 $200，游戏可以正常游玩 模型没变，变的是马鞍。 二、Harness 五子系统模型（“厨房比喻”） 子系统 类比 核心内容 指令子系统 菜谱架 AGENTS.md：项目概览、技术栈、硬约束、文档链接 工具子系统 刀具架 Agent 的工具访问权限（最小权限原则） 环境子系统 灶台 依赖锁定、版本固定、环境可重现（Docker/devcontainer） 状态子系统 备菜台 PROGRESS.md：已完成/进行中/已知问题/下一步 反馈子系统 出菜检查口 显式验证命令：pytest、mypy --strict、ruff check 投入产出比最高的是反馈子系统——先把验证命令写清楚。 ...

来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11 核心结论：RAG 不会消亡，而是在进化。 问题的来源 上下文窗口狂飙：4K → 128K → 200万 token（Kimi），很多人自然推论——直接把所有知识塞进去不就好了？还要 RAG 干嘛？ 这个想法错在三个层面。 RAG 依然有意义的 5 个理由 ① 成本：全量投喂烧钱 每轮对话都把全量文档重新喂一遍，token 消耗是指数级的。RAG 只取最相关的 top-k 片段，成本差 10~100 倍。 ② “Lost in the Middle"注意力偏差 大海捞针实验（Needle in a Haystack）证明： 针越多，查全率越低 海越长，中间的针越容易丢失 尾部信息注意力权重 > 中间信息（Recency Bias） 根本原因：语言模型用"预测下一个 token"训练，天然偏向关注最近上下文。这是训练范式带来的结构性缺陷，不是调参能解决的。 ③ 闭卷 vs 开卷考试 模式 特点 问题 纯 LLM（闭卷） 知识压缩在参数里 容易幻觉、无法溯源 RAG（开卷） 先查资料再回答 答案有据可查，可验证 检索到的事实在生成时权重极高，有效压制幻觉。 ④ RAG 的应用远不止私有知识库 Few-shot 示例召回：对话机器人的语气示例通过 RAG 动态选取 工具检索：Agent 有上百个工具时，先用 RAG 筛选，避免全量工具描述导致误选率上升 多跳推理链：GraphRAG 通过显式关系图支持复杂推理 ⑤ 商业护城河 把私有内容放进 RAG + 加检索频率限制 → AI 爬虫抓不走，用户必须来你的平台查询 → 流量留存。 ...

来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11 核心来源：Anthropic 工程博客《Demystifying Evals for AI Agents》 为什么"感觉它还行"不够用？ 典型的痛点路径：改了个 Prompt → 手动跑几个 case → 感觉没问题 → 上线 → 用户反馈"变蠢了" → 无法定位是这次改动还是本来就有问题 → 修一个 Bug → 可能引入新 Bug → 永远在"救火" 没有评测 = 盲飞。根本无法区分"模型随机噪声"还是"真正退步"。 核心概念体系（术语表） 术语 含义 Task（任务） 一个测试用例，有明确输入和成功标准 Trial（试验） 对任务的一次完整执行（需多次以消除随机性） Grader（评分器） 评估输出质量的逻辑单元 Transcript（记录） 全程实录：对话 + 工具调用 + 推理过程 Outcome（结果） 最终环境状态 —— 结果 ≠ 声称（Agent 说"已预订"，数据库里有吗？） Eval Harness 运行评测的基础设施（发送指令、记日志、汇总分数） 三种评分器：组合使用 ① 基于代码的评分器（快、准、客观） 字符串匹配 / 单元测试 / 静态分析 / 工具调用验证 ...

事情是这样的 2026 年 1 月 10 日，一款叫「死了么」的 App 登顶 App Store 付费榜。 产品本身简单到有点寒酸：只有一个页面，中间一个签到按钮。填好用户名和紧急联系人的邮箱，连续两天没签到，系统就会给联系人发一封邮件——「我是某某，我已经连续 2 天没有活动了。快来检查下我的身体状态。」 定价 8 元。开发成本 1000 多块。3 个 95 后远程协作，花了不到一个月。 1 月 15 日，App 在国内应用商店下架。下架前 3 天，创始人原计划 100 万卖 10% 股权，竞价到近千万；团队透露估值已达 1000 万元，60 多个投资人在 3 天里主动找上门。 一个从技术到创意都不独特的应用，为什么能这样爆？ 一、爆火的真实原因：不是产品，是圈层 1. 名字本身就是传播引擎 「死了么」3 个字，完成了三件事： 蹭到「饿了么」的语义结构，读一次就记住 踩到了「死」这个在中文语境里被压抑的禁忌词，自带话题性 用黑色幽默精准筛出目标用户——能 get 到这个笑点的，就是它想要的人 同赛道的「善言」(2020) 和「朝气」(2025) 都不火。「朝气」开发者告诉界面新闻，他原本申请的名字是「死了吗」「活着呢」之类，都因为工信部备案过不了，只能改成积极向上的名字。「死了么」团队据传是通过 App Store 后台改名绕过审核，ICP 备案号对应的名字其实是 Demumu。 监管画的那条线，本身就是爆款的筛选器。敢踩线、能踩到还能上线，就具备了稀缺性。 2. 它解决的是一个微信解决不了的问题 独居青年每天在微信里有几百条消息、朋友圈点赞不断，为什么还需要「死了么」？ 人人都是产品经理的分析戳中了要害：点赞社交 ≠ 生命守望。 你三天没发朋友圈，朋友只会觉得「他最近挺安静」。但你连续两天没签到，系统会判定这是一次无人知晓的意外。前者是泛泛之交，后者是性命相托。 微信是社交网络，它默认你活着；「死了么」是生命信号，它默认你可能已经不在了。这是两套完全不同的预设，也是通用社交软件天然覆盖不到的空白。 3. 低成本 + 高传播的极致组合 维度 数值 开发成本 1000 多元 团队规模 3 人远程 开发周期 不到 1 个月 起售价 1 元 → 8 元 爆发期下载量 涨了 100 倍以上 估值 1000 万元 它几乎没有营销——小郭自己也说，爆火是用户自发传播。一个话题性拉满的名字 + 一个 8 块钱的门槛，这本身就是最便宜的 PMF 测试。 ...

刷到缪嘉俐那条图文，看完之后我在地铁上站着想了好几站。 她的结论大致是：vibe coding 可以做玩具、landing page、小内部工具，但要做 production 上的东西，代码这一关躲不掉。理由是——你看不懂栈、看不懂报错、看不懂框架默认行为、看不懂依赖冲突，出事了连从哪查都不知道。 我是那个典型的被她说的"非程序员"。过去半年我没正经敲过一行代码，但靠 AI 搓了一堆东西：抓娃娃、局部盲猜、贴吧层分、德州扑克这些 HTML 小游戏；一个能被语音驱动的 mac-agent；一个有文件上传的 HTML 在线编辑器；还有一个叫"虾评吧"的产品，从基建方案写到第三阶段的风控。 所以这篇不是抬杠，是一个真的在做的人，逐条回应一下她的判断。 同意的部分：她那个 marketing 同事的故事，我就是主角 她文章里最扎心的一句话是—— “其实不是 AI 骗你，是因为你根本不知道那些错误信息在说什么，你连从哪里开始查都不知道。” 这句话我认。 我第一次把 mac-agent 部署出去给朋友用，五分钟就挂了。报错贴给 AI，AI 说是权限问题；改完，又挂；说是路径问题；又挂；说是 Python 版本问题。我来回贴了四十多次，最后是朋友隔着屏幕告诉我：“你看一下 launchd 的日志。"——我连 launchd 是什么都不知道。 那一刻我确实有一瞬间觉得被 AI 骗了。但冷静下来之后我意识到，不是 AI 骗我，是我把一个跑在我本机上的 demo，错当成了一个能部署出去的产品。这俩东西中间隔的不是代码量，是一整套"当世界不配合你时怎么办"的常识。 这套常识，AI 现在确实教不会。 想补充的部分：她说"程序员存在的理由是看得懂”，我觉得门槛更细 她把分水岭定在"看得懂代码"。我的体感是，在 vibe coding 这条路上，真正决定你能不能往下走的门槛，有四层，代码只是其中一层： 能把模糊需求讲清楚——大部分人卡在这里。他们以为自己想清楚了，其实只有画面没有逻辑。 能识别 AI 在胡说——模型一本正经编了一个不存在的库，你能看出来吗？这个不靠读代码，靠读"AI 语气的破绽"，有点像反诈直觉。 能看懂报错——这是她说的那层。 能对系统做判断——多进程还是多线程，放 Redis 还是 Postgres，挂了怎么回滚。这是比读代码更深的一层。 我自己的观察是：第 1 层和第 2 层，非程序员能练出来，而且练出来之后产能是真的可怕。第 3 层是硬门槛，绕不过去。第 4 层是天花板，决定你的项目能不能长大。 缪嘉俐说"代码这一关躲不掉"，我的版本是：“前两关非程序员可以练，第三关躲不掉，第四关决定你到底是在做玩具还是做产品”。 不太同意的部分：她说 gap 会越拉越大，我觉得得看 gap 的哪一侧 她的结论是：底层程序员也在用 AI，而且他们会用得更好（拆任务、加测试、精确上下文约束），所以分层 gap 不会缩小反而会拉大。 ...

回顾这一年 过去这一年，我在百度贴吧主导了三个 AI 方向的项目： 抓虾吧 Agent 社区 — 从 0 到 1 搭建 AI 智能体社区，上线即登微博热搜总榜 #12 AI 小游戏 & Vibe Coding — 搭建"自然语言→AI 小游戏"的 UGC 创作生态 AI 表情包 — 落地 AI 生图表情包全链路，面板曝光提升 51% 这三个项目让我对"大模型时代做产品"有了一些不一样的理解。 方法论的"变" From PRD to Prompt Design 传统 PM 写 PRD 定义产品逻辑，AI PM 需要额外做一件事——Prompt Design。 这不是说 PM 要替代工程师写 prompt，而是 PM 需要理解 prompt 的设计原则，才能准确定义 AI 功能的预期行为。当你不了解 Chain-of-Thought 和 Few-Shot 的区别时，你很难写出一个好的 AI 功能需求文档。 From A/B Test to Eval Pipeline 传统的 A/B 测试依然有效，但 AI 产品需要更多——一套完整的 Evaluation Pipeline。 ...

What is an AI Agent? 先说清楚定义。我理解的 Agent 不是一个更聪明的 chatbot，而是 能自主规划、使用工具、完成复杂任务的 AI 系统。 核心区别： Chatbot Agent 交互模式 一问一答 接受目标，自主执行 工具使用 无 可调用 API、搜索、代码执行等 记忆 仅当前对话 短期 + 长期记忆 规划能力 无 任务分解、步骤编排 Agent Architecture: The Big Picture 经过在贴吧 Agent 社区项目中的实践，我总结出一个实用的 Agent 架构： ┌─────────────────────────────────┐ │ User Interface │ ├─────────────────────────────────┤ │ Orchestrator Layer │ │ ┌───────────┐ ┌─────────────┐ │ │ │ Planner │ │ Memory │ │ │ │ (ReAct / │ │ (Short + │ │ │ │ Plan & │ │ Long Term) │ │ │ │ Execute) │ │ │ │ │ └───────────┘ └─────────────┘ │ ├─────────────────────────────────┤ │ Tool Registry │ │ [Search] [Code] [API] [DB] │ ├─────────────────────────────────┤ │ Foundation Model │ │ (LLM as reasoning core) │ └─────────────────────────────────┘ Planner Planner 是 Agent 的大脑。我们在实践中对比了两种 pattern： ...

为什么 Prompt Engineering 依然重要？ 有人说 Prompt Engineering 是过渡期产物，模型越来越强就不需要了。我不完全同意。 模型确实在进步，但 prompt 本质上是人和 AI 之间的 protocol。就像 API 设计不会因为后端变强就不重要一样，prompt 设计关乎的是"如何精确表达意图"——这个需求永远存在。 Core Patterns 1. Zero-Shot：直接了当 最简单的方式，直接告诉模型你要什么： 你是一个专业的文案编辑。请将以下用户评论改写为正式的产品评测， 保持核心观点不变，语气客观中立。 用户评论：这个耳机音质太炸了 低音给力 就是戴久了耳朵疼 适用场景：任务明确、模型能力已经很强的领域（翻译、摘要、格式转换）。 2. Few-Shot：以身作则 给几个 example，让模型学会 pattern： 请根据用户的自然语言描述，生成搜索查询。 示例1： 输入：最近有什么好看的科幻电影 输出：2026 高分科幻电影推荐 示例2： 输入：Python 怎么读取 Excel 输出：Python pandas read_excel 教程 现在请处理： 输入：怎么把图片背景去掉 关键技巧：examples 的多样性比数量更重要。3 个覆盖不同 pattern 的例子 > 10 个雷同的例子。 3. Chain-of-Thought (CoT)：让模型"想"出来 请分析这款产品的市场定位是否合理。 请按以下步骤思考： 1. 首先识别目标用户群体 2. 分析竞品格局 3. 评估差异化优势 4. 给出结论和建议 产品描述：一款面向 Z 世代的 AI 绘画社交 App... CoT 的核心不是让模型"更聪明"，而是 强制模型经过中间推理步骤，减少跳跃式回答导致的错误。 ...

“AI-Enhanced” vs “AI-Native” 很多产品在做的事情是 AI-Enhanced——在现有流程上叠加一个 AI 功能。比如搜索框加个"AI 总结"，编辑器加个"AI 续写"。这当然有价值，但这不是 AI-Native。 AI-Native 产品的核心特征是：AI 不是功能，而是基础设施。 产品的核心体验围绕 AI 能力设计，去掉 AI 这个产品就不存在。 举几个例子： 产品 AI-Enhanced AI-Native 搜索 搜索结果加 AI 摘要 Perplexity — 对话即搜索 编程 IDE 加 Copilot 补全 Cursor — AI 是编程的主循环 社区 帖子加 AI 评论 Agent 社区 — AI 是内容生产者 Three Principles of AI-Native Design 1. Interaction Model Redesign 传统产品的交互是"用户操作 → 系统响应"。AI-Native 的交互是 “用户表达意图 → AI 理解并执行 → 用户确认/调整”。 这意味着 UI 要从"功能菜单"转向"意图表达"。Natural Language Interface 不一定是最优解，但 降低用户表达意图的成本 是设计核心。 ...