checklist
写代码 checklist
注意位置
注意顺序
注意初始化
注意返回值
注意注释
注意防御性编程
注意数据库性能
上线 checklist
代码变更 check 代码
配置变更 check 配置
系统变更注意上线顺序
依赖中间件变更注意配置中间件
配置中心配了吗
交互所有细节都实现了吗？
配监控和埋点
数据库变更了吗？
安全检查
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-05-23
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份，也不是给系统加几个“人格”。它有效的地方，是把一个会互相稀释的上下文问题，拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布，很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值，是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比：复杂任务像一段混合信号，包含多个频率分量叠加。单 Agent 试图同时处理所有频率，相当于用一个宽带滤波器——信噪比低，各分量互相干扰。多 Agent 相当于用一组窄带滤波器，每个只提取自己负责的频段，互不干扰，最后再合成输出。 模型的注意力也有这个问题。任务越大，上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益，就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...
2026-07-01
AI 是放大器不是方向：读 Adam Bender 谈软件生态学的 10 倍时刻
引子：10 倍代码不等于 10 倍工程 Google 首席软件工程师 Adam Bender 在 Google I/O 2026 的一场演讲里抛出大多数人还没来得及思考的问题：当 AI 把代码产出速度推到现有工程流程无法承载的地步，开发者生态系统里什么会最先垮掉？ 他的回答直白：今天构建软件的方式，在 10 倍速度下根本行不通。AI 时代的真正赢家不是产出最高的团队，而是基本功最扎实的那些人。AI 只负责放大，不负责方向。 这场演讲串起一个大多数人没听过的概念：软件生态学，对生产软件的社会技术生态系统进行整体性研究的学科。它要求不只看技术，还要看人、看文化、看组织里那些不成文的规则。 flowchart TB subgraph Eco["社会技术生态系统（软件生态学的研究对象）"] direction LR Culture["工程文化<br/>组织结构 · 激励机制"] Practice["工程实践<br/>审查 · 测试 · 发布"] ...
2018-10-08
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
2018-05-09
Convention over Configuration over Programming
什么是 Convention over Configuration over Programming 在软件工程中，有一条重要的设计哲学层级： Convention over Configuration over Programming 约定优于配置，配置优于编程。 这条原则的核心思想是：能用约定解决的问题，就不要引入配置；能用配置解决的问题，就不要写代码。 它反映了软件设计中对复杂度管理的追求——越是高层次的抽象，使用成本越低，出错概率也越小。 三个层次的含义 Programming（编程） 编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源，都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration（配置） 配置是介于约定和编程之间的中间层。通过外部化的配置文件（如 XML、YAML、properties 等），开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本，但引入了配置管理的复杂度——配置项越多，理解和维护系统的难度就越大。 Convention（约定） ...
2026-05-23
环境可供性：智能的一半是取到正确数据
没有工具的模型，只能靠提示词获得额外信息。提示词工程在那个阶段几乎是唯一杠杆：把背景写清楚，把例子给够，把格式约束好，让模型在已有上下文里尽量选对路径。 一旦模型拥有主动提取外部数据的能力，问题就变了。智能不再只取决于模型内部能处理多少信息，也取决于它能不能从环境里拿到正确的信息。 Prompt 是喂信息，工具是取信息 prompt-only 系统的工作方式像开卷考试，但试卷、教材和草稿纸都必须提前塞进同一个信封。用户没塞进去的信息，模型默认看不见。它可以猜，可以泛化，可以从训练数据里补常识，但无法可靠知道当前项目、当前日志、当前数据库、当前 API 文档发生了什么。 工具调用改变了边界。ReAct 把 reasoning 和 acting 交织起来，让模型一边推理，一边对外部知识库或环境采取动作获取观察结果。Toolformer 进一步证明，语言模型可以学习在合适时机调用 API，并把结果纳入后续预测。SWE-agent 的核心贡献也不是“又写了一个 coding prompt”，而是强调 Agent-Computer Interface：给 agent 一个适合读文件、改...
2026-05-20
Harness Engineering：长程 Agent 的工程化底座
微信公众号文章《Harness Engineering：让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点：Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的，但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”，还是太窄。 更准确的定义是：Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环，让 Agent 能跨越单个上下文窗口，持续推进真实任务，并在失败时留下可恢复的证据。 这不是 Prompt Engineering 的升级版，也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说，Context 解决一次请求里放什么，Harness 解决的是任务生命周期怎么被系统托住。 一、为什么 2026 年突然轮到 Harness OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验：团队从空 Git 仓库开始，用 Codex 构建并发布一个内部...