技术实现
1 ) 反复造轮子
这是一个软件开发的经典问题，即便在 vibe coding 时代，在开发中造轮子也是一个 ROI 极低的选择。
这里回溯一下当时的场景，要实现的功能 markdown 格式的清洗， 为传入 TTS 前做准备，当时的心态不是嫌弃开源方案的实现，而是低估的简单功能的实现复杂度，导致 md 解析时忽略了很多 edge case
总结，开发阶段应该有一套固定的 SOP，需求明确后去找相关的开源实践，务必做好 system design 后在落代码
2 ) 开发规范
我得承认，在项目开发阶段，我对繁琐的流程是及其排斥的，无论是文档、还是流水线规则（客观说这里确实有 GUI 配置过于垃圾的问题），都反复消耗我的注意力。
但是到项目的后期， 前期对开发规范的疏忽，让团队整体消耗了更多的时间。
具体列几个点：
- 测试用的 mock 数据，提测时间提前了，到时很多问题没暴露
- 没走标准开发环境
- 流水线没有走组织模板
”遵守开发规范，不是局部最优解，但是是全局最优解“
说来我一向是一个不愿意遵守各种 “规范” 的人，特别是在学校里，常常被各种规定恶心。但现在才意识到，这不是规定的问题，是规则的制定者和个人利益不一致，但是在开发场景下，显然利益是一致的，需要重视开发规范
3 ) 可观测与长尾问题
这两个问题放在一起讲，可观测说的是日志问题，日志要尽可能的详细，由于部署人员无法用Codex 去捞日志，模糊、混乱的日志，会对部署造成极大的阻碍
长尾问题指得是，开发中常见的一种心态是实现了核心功能后，其他的都是小事。坦白说，这种心态贯穿着我的学习和工作，在严谨的软件工程下，这个问题是致命的。这里给自己提出两个要求：
- 自测，不能把测试问题甩给开发人员，特别是 vibe coding 时代
- 心态上的摆正，根据经验，在一个完整的开发周期中，实现核心功能可能只占到完整周期的不到一半时间，必须重视长尾需求
4 ) 镜子
代码不会撒谎，生产环境是一面镜子，表面上是技术问题，实际上这些问题贯穿着我的学生生涯，是我的性格底色
改变很难，但必须做