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
智能体外部记忆：文件标准现状与超越 Harness 的更广泛用途
当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式？除了用在 Harness Engineering 里，还有哪些更广泛的用途？本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战，以及超越 Harness 的更广泛应用场景。 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此，业界已经形成了几个被广泛认可的...
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...
2018-10-08
系分方法论交流笔记
分析、设计和架构的区别 系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头 要理解： 架构约束 项目约束 要有： 权衡 选择 的过程 理解业务，要理解业务背后的东西，产出的是模型。 一步一步走，推演出来解决方案，要有方法论。 系统设计是很明确的工作了 应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题： 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论 用例驱动设计 SOAD 面向服务的分析和设计 OOAD 面向对象分析和设计 DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。 这几种方法论可以混合使用。 需求分析与业务建模 把 prd 从薄读到厚，把文档中缺失的部分补全。 系分做 PRD 评审的时候，影响比较大的点一定要尽早确认。一些对系统变化可控，可预测的变化，可以暂时放过，后续在补充。 面向服务的业务建模 分析主业务服务，设计业务功能域，设计业务功能域边界。这个过程可能不断地螺旋式地重构。 如果用...
2019-12-13
CI/CD 方法论
CI/CD 的重要性 Martin Fowler说过，“持续集成并不能消除Bug，而是让它们非常容易发现和改正。” 持续集成和持续交付作为敏捷开发的一种最佳实践，通过包括构建、部署、测试、发布流程的自动化，实现质量内建，让质量问题可以快速发现和消除，从而提升软件交付的质量和效率。 基本策略 分支模型是CICD落地的源头，研发过程各角色间的协作方式以及研发过程内代码版本的流转方式都取决于分支模型。 首先划分环境。 划分环境后设计分支，注重开发和发布两个场景。 根据分支设计流水线，验证应该发生在全流水线里。 一般的分支模型 参考文献： 《在阿里，我们如何管理代码分支？》 《What is Trunk-Based Development?》 《提升团队的微服务落地能力》
2018-10-08
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
2026-03-18
在智能体优先的世界中利用 Codex
原文作者：Ryan Lopopolo，OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里，我们的团队一直在进行一项实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计，我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制，以便构建必要的内容，从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此，我们需要了解，当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。 这篇文章要说的是，在我们与智能体团队一起从零开始打造一款全新产品的过程中，所...