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-03-18
在智能体优先的世界中利用 Codex
原文作者：Ryan Lopopolo，OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里，我们的团队一直在进行一项实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计，我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制，以便构建必要的内容，从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此，我们需要了解，当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。 这篇文章要说的是，在我们与智能体团队一起从零开始打造一款全新产品的过程中，所...
2026-05-23
Harness 的本质：把随机模型锁进可验证的箱体
把大模型当成一个确定性函数，很容易高估它。更合适的工程抽象是：模型在当前上下文、参数和工具环境给出的概率空间里，采样出一个看起来最合适的结果。 这意味着同一个模型在同一类任务上的能力并不是一个点，而是一段分布。一个平均能做 70 分的模型，在某个具体任务上可能落到 50 分，也可能冲到 90 分。Harness Engineering 的价值，不是把 70 分模型魔法般变成 95 分模型，而是把它的行为压进一个更小、更可验证的区间，让低分尾部少出现，让高分路径更容易复现。 这个区间可以叫“箱体”。Spec、测试、工具、循环、权限、外部状态、子 Agent、hook，都是箱体的不同面。没有箱体时，模型在荒野里寻路；有箱体时，模型在一条被标出边界和检查点的路线上前进。 flowchart TB A[用户目标] --> B[Spec: 目标 / 非目标 / 边界] B --> C[Plan / Tasks] C --> D[模型生成候选方案] D --> E[确定性工具: 编译 / 测试 / schema / 日志] ...
2018-10-08
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
2026-05-23
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份，也不是给系统加几个“人格”。它有效的地方，是把一个会互相稀释的上下文问题，拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布，很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值，是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比：复杂任务像一段混合信号，包含多个频率分量叠加。单 Agent 试图同时处理所有频率，相当于用一个宽带滤波器——信噪比低，各分量互相干扰。多 Agent 相当于用一组窄带滤波器，每个只提取自己负责的频段，互不干扰，最后再合成输出。 模型的注意力也有这个问题。任务越大，上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益，就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...
2018-10-08
系分方法论交流笔记
分析、设计和架构的区别 系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头 要理解： 架构约束 项目约束 要有： 权衡 选择 的过程 理解业务，要理解业务背后的东西，产出的是模型。 一步一步走，推演出来解决方案，要有方法论。 系统设计是很明确的工作了 应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题： 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论 用例驱动设计 SOAD 面向服务的分析和设计 OOAD 面向对象分析和设计 DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。 这几种方法论可以混合使用。 需求分析与业务建模 把 prd 从薄读到厚，把文档中缺失的部分补全。 系分做 PRD 评审的时候，影响比较大的点一定要尽早确认。一些对系统变化可控，可预测的变化，可以暂时放过，后续在补充。 面向服务的业务建模 分析主业务服务，设计业务功能域，设计业务功能域边界。这个过程可能不断地螺旋式地重构。 如果用...
2018-03-07
语义版本化问题
语义化版本 2.0.0 《语义化版本 2.0.0》，三段版本号语义： 版本格式：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH），版本号递增规则如下： 主版本号（MAJOR）：当你做了不兼容的 API 修改， 次版本号（MINOR）：当你做了向下兼容的功能性新增， 修订号（PATCH）：当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面，作为延伸。例如 1.0.0-alpha、1.0.0-beta.1、1.0.0-0.3.7。 版本号的初始阶段 在主版本号为 0.x.y 的阶段，API 被认为是不稳定的，任何变更都可能发生。这个阶段的软件不应该被用于生产环境。1.0.0 的发布意味着公共 API 的正式定义，后续的版本号变更都基于这个公共 API 的变化来递增。 先行版本号（Pre-release） 先行版本号通过在修订号后面加上连字符和一系列以点分隔的标识符来表示。例如： 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-b...