做点有意义的事

本文包含 AI 辅助创作内容 目录 背景 Harness Engineering 解决什么问题？ Prompt Engineering 解决什么问题？ Context Engineering 解决什么问题？ Harness Engineering 解决什么问题？ Agent 可靠执行需要解决的问题 可观测性 治理与安全 Memory 管理 测评与评估以及训练 Agent 测评体系的三个层次 评估基础设施 Evals 驱动的提示词优化（轻量级训练） 评估与训练的飞轮（Eval-Train Loop） Judge 机制的选择 所以最后，Harness Engineering 是什么呢？ 背景 昨天有一个二面的面试，我感觉她说的挺有道理的，有许多是我之前做过但是没有真正认真想过的。主要内容是关于如何做一个类 Claw 的产品，以及做这种类 Claw 产品的核心竞争力。 其中就涉及到「Harness Engineering」，因此这篇文章，我就从初学者入手，做一些资料收集和总结。后续我会挑选一个之前实现的 Agent 来做，再写另外一篇实践的文章。 Harness Engineering 解决什么问题？ 介绍 Harness Engineering 之前，我们看看它试图解决什么问题。 在这之前，我们还可以更先看看 Prompt Engineering 和 Context Engineering 解决了什么问题。 Prompt Engineering 解决什么问题？ 核心问题：如何正确地向 AI 下达指令（意图表达与对齐） 痛点：早期大模型（LLM）虽然聪明，但往往是非确定性的。如果提问方式不对，它会输出不符合预期的结果。 解决方案：通过精心设计输入文本（如 Few-shot、Chain-of-Thought、角色扮演等技巧），引导模型按照人类的期望进行推理和生成。 作用范围：单次交互（Single Interaction）。它关注的是”我们该怎么问”（What should be asked）。 主要关注一次 LLM 调用的提示词编写。 Context Engineering 解决什么问题？...

本文包含 AI 辅助创作内容 目录 前言 解读 第一章：智能体质量的四大支柱 第二章：由外而内的战略框架 第三章：可观察性 第四章：结论 可信 Agent 的三个原则 前言 这个文章是一个多月前对谷歌的 Agent Quality 白皮书的阅读摘要。 原文阅读：https://www.kaggle.com/whitepaper-agent-quality 系列文章汇总：https://cloud.google.com/blog/products/ai-machine-learning/a-devs-guide-to-production-ready-ai-agents 建议直接阅读原文，这里是一个读书笔记，比较粗糙。 解读 衡量 Agent 质量，不是最终输出的评估，真正标注是整个决策过程 观测性是基础 无法观察的过程无法评估 观测性三大支柱 日志记录 追踪 指标 评估是一个持续循环 可扩展的 AI 驱动评估器 人类参与（human in the loop） 第一章：智能体质量的四大支柱 四大支柱 有效性 效率 鲁棒性 安全 要点 传统 QA 对确定性系统有效 失败并非代码错误，而是判断出错 传统 QA 按照固定规范来验证逻辑 Agent 的评估，在动态和不确定的世界中验证、评估质量、稳健型、可信度 Agent 面对的问题 质量细微退化 具有隐蔽性 算法偏见 → 训练中的系统性偏见的数据 事实性的幻觉 → 高置信度给出事实错误和虚假信息 概念漂移 → 真实世界的变化导致原始训练数据逐渐失效 突发意外 → 无限循环 or 反复编辑 根本原因需要 1. 深度数据分析 2. 模型再训练 3. 系统性评估...

年前再次带一个新人。抽出时间 + 借助 AI, 我想了一下，我心中的的后端工程师的试用期目标。 简而言之，也就是，「如何判断一个人真正变成了我们的人」。 这是 如何做好一个后端 的系列文章，我想多写一些文档，总结一下阶段性的成果，特别是 AI 时代来临了，如何保持和培养自己的工程师素养。 目录 目录 代码级别的标准 代码质量与规范 复杂问题定位与解决 AI 使用经验 工程架构师的标准 架构设计能力 复杂项目实施 对外合作与沟通 文化认同与软性素质 文化认同 基本素质 做的更好？ 关注外部 个人价值实现 未来规划与长远发展 代码级别的标准 核心：考察其是否具备解决深层、复杂技术问题的能力，以及代码是否具备生产级质量与可维护性。 简而言之，也就是一些细节层面的考察。 代码质量与规范 主要关注 MR 能写出合格、干净的代码 能 Review 别人的代码，并给出有效评论（避免无脑 Approve) 能接受别人的 Review 并根据实际情况修改代码或做出解释 对代码质量有追求 能主动优化系统存量代码 写代码会关注性能、技术前瞻、接口设计 复杂问题定位与解决 主要关注值班 oncall 处理 能心平气和沟通、认真对待用户、运营、产品的 oncall 并跟踪解决 熟练使用公司平台的排查能力，处理排查线上问题 包括不限于 sentry/logging/profile/grafana 等 能追踪并彻底解决一个疑难问题 能主导某个故障的根因分析，并推动解决 在事故复盘时，能超越表面现象，指出系统设计、流程或协同上的根本原因，并提出长效改进措施。 能够在需求中对解决问题进行代码补充 合理打日志+打指标 灰度与放量 产出一些缺失的规范 AI 使用经验 主要关注 MR 以及观察日常使用情况 能够熟练使用 Cursor / Claude Code 等类似 AI Coding Agent 产品写代码 能够评估...

起因 之前在网上看见很多人说 anki 很好用，就想能不能用 AI 做点 anki 包来挂到淘宝上面出售，挣点钱? 通过搜索和询问 AI 调研，我发现3个领域比较火热没必要做， 1. 语言学习(特别是英语) 2. 初高中应试科目 3. 中医考试。通过类比，感觉 编程八股 + Anki 可能是一个不错的领域，想写点脚本来试试。 恰好最近面试又碰到一些面试八股的问题，我只好说尴尬的和面试官说这块儿我忘了，前几天刚好想了一下，可以用这个方式拿来练手做一个真正实际意义的垂直的 Agent 应用，而且编程八股 + Anki 说不定有搞头？(不知道有没有人真的用 anki 来背诵面试八股呢? ) 最终成品 网站 https://ankiany.starsou.com/ 可以制作任意主题的 Anki 包 根据原神生成的对应的卡牌提问。。。 1. 国家队"万达国际"的核心成员包括谁？||达达利亚、万叶、班尼特、香菱 2. 雷神国家队"雷国"的成员配置是什么？||雷电将军、行秋、香菱、班尼特 3. 深境螺旋的刷新时间是什么时候？||每月1日和16日 4. 体力满180树脂时，多长时间会溢出？||约24小时 5. 下列哪个配队不适合处理遗迹守者？||A. 万达国际 B. 雷国 C. 永冻队 D. 纯火队||D. 纯火队（遗迹守者有火抗性） 6. 刷圣遗物时，哪个副本最适合物理主C角色？||苍白之火炽炎之狮祠堂 7. 面对大型群体敌人时，哪个角色的大招清场能力最强？||温迪或流浪者（风元素扩散） 8. 武器池的定轨规则是什么？||连续2次未获得当期UP武器后，第3次必定获得UP武器 9. 哪个角色在面对深海龙蜥时有特殊的克制效果？||宵宫（火元素对龙蜥有额外伤害） 10. 副本"华池岩岫"主要产出什么材料？||华池木和琉璃袋等璃月特产 11. 角色突破材料中，最需要优先囤积的是什么？||天赋书和武器突破材料 12. 在元素反应链中，火元素附着后多长时间会消失？||约9.5秒 13. 深境螺旋中，敌方等级的上限是多少？||100级 14. 面对高元素抗性的敌人，应该优先考虑什么？||物理伤害或降低抗性的手段 15. 哪个圣遗物套装最适合辅助治疗角色？||海染砕鸣或被怜爱的少女 能够生成某个主题下面常见知识的 anki 包 比如这个 “MySQL...

引子 应该要从 3 月说起，多年之前认识的一个创业者问我说，有没有时间兼职做一下 AI 应用研发，我当时答应了下来。昨天为了写这篇文章，我去查证聊天记录，发现他早在 24 年 9 月就在问我有没有认识的 AI Agent 研发方向的朋友，当时回复了周边没有。事后看来，我对他的印象又刷新了。 摘要 本文会先描述 2025 我使用 AI 开发的几个典型阶段。最后会做一个总结以及关于 AI 时代我的一些思考。 Vibe Coding 的各个阶段 在时间顺序上交错并行前进的。 1. VSCode + cline + deepseek 初期，就靠这 3 件套来进行低成本的 AI 开发，给我最深的印象就是写完一个 Chrome 插件，发现用了几块钱。 关于这段时间的经验总结，可以参考这个回答：有什么办法在 deepseek 的两段对话间传递信息吗？ 合理分配拆分任务 聚焦当前对话的任务 减少任务大小 合理拆分文件 及时总结上下文 最让我难受的就是 64K 的上下文，往往引用一个复杂的 html 就导致占用了 38k 导致根本没法修改。后来我学会了，让他单独写 js 和 html 不要总是在一个文件里面。在每次修改前我会告诉他读取什么文件，写入什么文件。最后我再来验证。 2. 从 Prompt 到 Cursor Rules 同一时期，公司里面开通了 cursor 的试用账号，大概有一个月的体验期，感到很新奇，比上面的三件套用起来丝滑了一些。这段时间就是开始疯狂的用 AI 写代码，到了有一种无脑信任的地步。后来针对一些重复/常见的迁移任务，我们也总结了不少 mdc 文件。从一开始的临时 prompt，精调 Prompt 再到最后的 Cursor rules，mdc 文件。 这段时间的经验总结，是发在公司内网 wiki 的，大概是这样的。 原来的代码质量会深刻影响...

目录 补充明确的验证手段 编译通过 Web 界面操作步骤 sqlite3 数据库 python 片段代码 为 AI 提供可验证的环境/文档 本地可跑单测的能力 本地全套运行环境 正文 我觉得是验证结果的手段缺失的问题。 题主说的体验我最近只在 GLM 4.6 的claude code上面体验到，一些比较复杂的难题，总是倾向于使用 mock 代码占位、假装构建成功等等，给人一种总是想连忙结束会话的感觉，等我去检查的时候发现编译是不通过的。 使用 Gemini/Deepseek 3.2 的时候，体验会好一点。对于我不懂的 Rust 在 Mac上面交叉编译 Windows msvc 版本的难题， 我会告诉它，最终的目标是编译成功。所以中间的代码分析/头文件缺失/mingw和llvm的安装，他尽管可以任意发挥，只要最终能够编译成功，就是有用的。可能中间的代码或者解决方案对于精通 Rust 的人来说是不达标的，但是对于外行来说，只看疗效并不看代码质量。只要不报错，编译通过，运行还可以，就是完成任务了。 我还在写 Web 网站时候发现，只描述功能和预期是不够的，写得前后端代码效果总是在某些地方不如人意，有时候是提示词里面没有说清楚，有时候是另外一个功能的代码破坏了另外一个功能。还要有验证手段，我会让 AI 参考功能流程，使用 chrome devtools mcp 来进行测试/验收/Debug，它能够访问首页，点击登录，输入密码，最终登录成功，输入关键词，点击搜索，并看到最终的表格效果。如果我告诉他某个按钮点击没反应，它是能够 debug 出来这个按钮的事件被另外一处 js 监听了，最终给的解决方案可能很抽象（我虽然是后端，我也能够看出来它写的不是好代码），但是对用户来说，能够跑通就行。 在写一些后端代码得时候，有能够复现的工作环境是最好的，比如写一个脚本的时候，AI 会自动去帮忙编译执行验证，如果代码依赖的配置/数据库/其他依赖导致项目只能在 prod 跑起来，就没法在本地验收确认结果了，这种是最难的，体验差的时候，需要人工在本地IDE和线上运行环境中间反复粘贴代码，甚至包括复制运行日志给 AI Debug。所以要要求写后端代码的时候，必须能在本地 IDE 能跑起来，能准备好数据库/配置/其他依赖能资源，能够让 AI 来写单元测试，来执行单元测试，启动服务器，验证 /api 接口。 这部分体验最好的还是写 python 项目的代码，几乎任意片段代码 ai 都可以 import 进行验证。数据库是 sqlite3 的时候，体验也是很好的，ai 可以直接验证 sqlite3 里面有没有数据，表的 schema 是什么，是否需要根据需求进行 DDL等等。运行起来的所有日志ai也是可以自己读到的。 我的体验来说，只要给出验证手段，在铁一样的失败结果面前，AI 只会羞愧地反复道歉，不会再自吹自擂了。当然有可能成功之后的代码可能看起来还是狗屁不通的。

cline + deepseek 低成本AI 编程的一些体验总结 intro 在使用大善人的 gemini 之前(现在天天用)，我用了一段时间的 cline + deepseek 来开发了一些软件（没有用公司的cursor的原因是我想体验一下这个组合，也避免一些问题)。 今天看到这个问题 有什么办法在deepseek的两段对话间传递信息吗？ 有一些想说的，就来做个体验总结。 Part2 前段时间，用了一段时间 cline + deepseek ，也碰到这种问题（受限于 64K上下文），我总结一下我的感受和一些方法。 省流: 事前、事中、事后多让 AI 写总结文档。人为拆分任务，确保每次会话聚焦特定任务。 合理拆分任务 可以在开始做之前就使用AI 描述你的整体需求，拆分合适的开发计划。把代码实现拆解为多个阶段，每个阶段的主要解决的问题。可以让 AI 把这些计划总结出来，比如把总体产品文档总结为 product.md ，把整体技术架构和开发计划总结为 tech.md ，把某个特定领域的开发计划总结为 tech.xx.md 。提供不同颗粒度的文档，这样后续新对话前时候，可以手动让 AI 先读取这些总结过的文档，知道我们要干什么，让他做好准备。 当然这里的文档要仔细甄别，甚至上手调整，AI 的规划文档里面多了一个技术名词，可能就会导致后面生成大量无关的代码。 聚焦对话任务 聚焦对话任务，有两个好处，1. 容易评估会话的结果，2. 丢弃会话成本低。 不论是实现第一次的初始化，还是实现某次的 Bug 修改，都可以只让它完成这次任务就行。完成了，基本合格，就可以提交保存了。这样再下一次新会话的时候，如果聊的不好，完全可以删掉重来。一次对话，读取合适的上下文文档和代码，完成某个小点就可以了。 比如同一个功能，可以先让他根据产品需求设计后端的模块和接口文档，这一份文档可以分别在两个会话里面，分别去实现后端接口，和前端代码。而如果糅合在一个会话里面，往往就超过上下文限制，导致无法产出可用结果。 另外，在实践过程中，有时候在会话中突然聊起别的事情，还容易把AI 搞混了。 减少任务大小 之前碰到调整一些历史代码的场景，合理控制代码文件大小，也是一个有效的手段。对于那种把 html / js/css 都写到同一个文件的代码来说。用 deepseek 这样的上下文的 api 是很困难的，说不上两句或者没输出完整代码，就超了64K。 可以手动或者让 AI 来做这样的模块化分割，减少同一个文件的内容/知识。合理结构的代码目录和适当的代码分割也更容易满足上面的第二步的要求。 需要注意的时，让AI 生成代码的时候也这么做，比如最开始后端接口只在一个 server/index.ts ，稍不注意他可能每一个接口都塞到这个里面来了。需要在会话开始时，指导它要将某个领域的接口写入到单独的文件里面来。 及时总结 如果会话的过程中，发现改动计划调整比较大，可能64K 上下文不够用的时候，可以及时停止代码生成，反而要求它总结当前的改动计划，调整哪个文件的哪个地方。挽救一下沉没成本。 下一次会话的时候，可以阅读这个临时的改动计划文档，先改第一步。改动完成之后，再开启新会话，读取这个改动计划文档，告诉他第一步已经改完了，请他按第二步调整。如此如此。 一些其他的使用体验 细碎的文件名 在一些大型项目里面，分层比较多，导致代码可能有十多个 user.go 或者 user.py， 很难选择出哪一个...

马上就是 2024 最后一天了，我想还是写点东西给 2024 留个纪念吧，免得又是悄悄度过了一个没有记住的年份。 写一下自己在工作之外写的一些代码，算是在这个世界做了一点有意义的事。 主要是两个方向。 Go Linter 起源还是在工作中发现了自己或别人犯的一些小错误，感觉是一些常见的模式，就想实践了一下，看看能不能检测出这类错误，避免再次踩坑。 创建了一个非正式的仓库 sundrylint ，我的一些 idea 会先粗略的在这个里面实现，如果有比较不错的，就会单独提出去。 实现和未实现的 idea 都列在仓库下面的#issues/2 里面了。 主要是如下几类错误 1. time.Parse 的参数顺序 func demo() { _, _ = time.Parse(time.DateOnly, date) _, _ = time.Parse(date, time.DateOnly) // 错误的用法 } // time.Parse 的签名 func Parse(layout, value string) (Time, error) { } Parse 函数的第一个参数是 layout, 第二个参数才是 value，因为两个都是 string，这个函数的签名是很容易混淆的。 补充了检查代码，跑了一下排名前1万的 golang 仓库，却只发现了2个错误（记录在 #issues/3），事实说明大多数人没用错。所以最终这个 idea 暂时搁置了。 2. RangeAppendAll 的误用 这也是一个很常见的错误，在我们的项目里埋伏了2年才被发现。 func collectBigger(ns []int, k int) []int { rs := make([]int, 0) for _, n...