拾光·时光机

1. 意图定义和精确规格写作：把业务痛点转化为清晰需求、验收标准、输出格式、边缘案例 2. 批判性代码审查与调试心智模型：必须能读懂 AI 代码，找出隐藏 bug，安全漏洞、坏抽象、违反分层规范的问题。而建立强大心智模型的最好方式是：手动实现核心概念，再让 AI 辅助 3. 软件工程基础与“底座思维”：深入理解分层架构…

第一篇发布文章，用于验收内容管线。

Keep this. Stay close.

从“会写”到“会判断” 对于技术选择，多问自己 > 1. 为什么是它？(我有什么理由选这个,而不是另一个?是真有理由,还是只是「大家都这么用」「我熟」?) > 2. 代价是什么？(选了它,我同时放弃了什么?将来会在哪里付出代价?)

Vibe coding 误区：AI 写完代码能跑就结束了 但在真实项目里，能跑只是第一步，还要看有没有破坏原有逻辑，有没有留下隐性问题，有没有让后期维护变难 所以写完代码要进行 review，而不是直接下一个需求 Review 一般要做 5 件事 1. 改动范围是否超出指令 2. 是否改了不该改的文件 3. 接口和数据…

#徒步 · 把这一刻留在时光机里。

> 谷歌Chrome负责人揭开Vibe Coding幻觉：AI只能帮你写出70%的代码！未来开发者培养方式将变化成三人编程 - 真正的 AI 驱动开发不是“快”，而是有意图的构建 - 如果只是"跟着 vibe 走"，我觉得在创意阶段、原型阶段是可以的，这个阶段更需要发散；但在工程阶段肯定不行，在工程阶段更需要“规范驱动…

Medium 上有好多文章都在说公司大规模引入AI编码工具后，会出现软件架构漂移问题，甚至会导致重大生产事故，比如 AWS。去年12月份 AWS 内部 Kiro 在处理 Cost Explorer 服务问题的时候，自主决定“删除并重建”整个生产环境，导致服务中断 13 小时，国内一大堆订单处理受影响。 AI 确实能给开…

AI 时代，团队需要有很多ai想法或者产品思维的人，而不是螺丝钉（随时会被替代），如果你的想法很值钱，就不容易被替代 模型的结果质量 = 需求明确性 + （提示词）上下文（大模型侧的视角，用户侧的视角是认知）「认知：对代码的理解、产品的理解、开发的理解等等，懂得越多能更好的压榨模型的能力」 人不可能比 ai 聪明，但人…

在vibecogding过程中，快速生成、想法变原型快效果很刺激。但容易陷入代码腐化的危机，如错误堆积、改动影响大、维护成本高，快速生成的是项目而不是可演进的工程。软件的最大价值在于可以规模化推广，也就是一次开发多次分发，以及收拢通用需求演进。现在的生成模式很难让软件进入“复利模式”，应该从生成模式演变成治理模式即冻结…