工程实践

从需求到上线这条路上的工程方法：怎样把需求切成可以验证的小块、怎样度量交付的流转，变更怎样保持兼容并且能回滚，配置推送与分支合并之后怎样确认真的生效，A/B 实验的结果怎样判断，怎样用 AI 辅助编码而不失去对代码的掌控，以及 Python 在并发与失败路径上的几个陷阱。

从哪里开始：先读把需求切成可验证的小块；关心发布安全的读者接着读能重新部署旧版本，不等于能回滚。

文章

01AI 辅助编码的工程纪律上下文管理、评审该盯哪里、自动化回归防线，以及哪些活不该交给 AI→02让模型产出数据，而不是导入脚本逗号切分与吞异常的假成功、BOM、引号与换行字段、Schema 校验、单事务导入→03能重新部署旧版本，不等于能回滚原地改名让回滚失败、扩展—迁移—收缩的每一步与不可逆点、旧消费者读新事件时悄悄丢数据→04上游加了一个字段，下游全部反序列化失败多一个字段时 Jackson 2 默认抛异常、Jackson 3 默认忽略；读改写会丢掉不认识的字段；Protobuf 保留未知字段，编号重用会把邮箱读成昵称→05出事的那几秒，日志恰好是空的Logback 异步队列快满时丢弃 INFO，1001 条只写出 207 条；队列满时阻塞业务线程或全部丢弃；关闭只等 1 秒；进程直接退出时一条不写→06配置中心显示已推送，线上行为没有变属性源改了，@Value 字段还是旧值；最大线程数改成 16，无界队列下线程仍是 4；root 调成 DEBUG 被显式级别挡住；HikariCP 启动后改地址被拒绝→07两个分支的检查都通过了，合并之后主干挂了没有文本冲突不等于合并结果正确；检查该跑在哪个提交上、合并队列；撤销合并提交后再次合并拿不回原来的改动；压缩合并后的原分支→08p 值 0.03，这个功能就该上线吗模拟 A/A 实验的 5% 误报、中途偷看升到 20%、样本不足时的漏报与夸大、分析单位、多指标与按天汇总的陷阱→09函数默认参数里的列表，为什么越用越长名字只是贴在对象上的标签：可变默认参数、乘法造出的二维列表、浅拷贝只复制一层、+= 的两种行为、闭包记住的是变量→10python -O 之后，参数校验全没了assert 在 -O 下被整条去掉、finally 里的 return 吞掉异常、with 不保证文件写完、子进程与线程池里无声的失败→11asyncio.gather 里一个任务失败了，其他任务还在跑gather 不取消而 TaskGroup 取消、被协程吞掉的 CancelledError 让超时失效、没有引用的任务被回收、阻塞调用与跨 await 的竞态→12Python 线程能不能用上多核CPython 3.14 默认构建 4 个线程只相当于 1 个核，free-threaded 构建 3.4 个核；去掉 GIL 之后不加锁的计数开始丢数据→13把需求切成可验证的小块按业务结果做纵向切片：缩短反馈距离、常用切法、切片的验收、Scrum 2020 的目标与完成的定义→14交付周期是多少天从状态事件重建周期：起点定义、重开、每日快照、处理与等待、未完成项、乱序与重复事件；指标不用于个人排名→