足迹·最近动态

1. 意图定义和精确规格写作：把业务痛点转化为清晰需求、验收标准、输出格式、边缘案例
2. 批判性代码审查与调试心智模型：必须能读懂 AI 代码，找出隐藏 bug，安全漏洞、坏抽象、违反分层规范的问题。而建立强大心智模型的最好方式是：手动实现核心概念，再让 AI 辅助
3. 软件工程基础与“底座思维”：深入理解分层架构（controller­­­s➔services­­­➔models）、monorepo 组织、统一日志/RBAC/审计/定时任务脚手架、DB 变更流程
4. Harness Engineering / Guardrails 设计：学会写 Rules（Agents.md）、创建安全 CLI 工具、Memory 记忆系统、自动测试+Reviewer 流程
5. Prompt Engineering：为 AI 提供高质量上下文如架构决策、规范、示例、最佳实践
6. 领域支持、业务判断、沟通力：深入垂直领域，理解真实痛点和权衡

博客管线跑通的第一天。

从“会写”到“会判断”

  会写              写得好            会做系统           会判断
(能实现)  ──▶   (优雅、健壮) ──▶   (拆得清、连得顺) ──▶ (知道为什么、
                                                     算得清代价)
  │                 │                  │                  │
「我能让它          「我能让它          「我能把它          「我知道这么做
  跑起来」           跑得漂亮」          搭起来」            换来了什么、
                                                      又放弃了什么」
  ▲                                                       ▲
  └──── AI 正在快速逼近、甚至超过这一段 ────┘            └─ 这一段,
                                                         只能靠自己

对于技术选择，多问自己

1. 为什么是它？(我有什么理由选这个,而不是另一个?是真有理由,还是只是「大家都这么用」「我熟」?)
2. 代价是什么？(选了它,我同时放弃了什么?将来会在哪里付出代价?)

正向的”懒“，让我学会更高效率的做事
清醒的懊悔，让我持续向上生长

Vibe coding 误区：AI 写完代码能跑就结束了
但在真实项目里，能跑只是第一步，还要看有没有破坏原有逻辑，有没有留下隐性问题，有没有让后期维护变难
所以写完代码要进行 review，而不是直接下一个需求
Review 一般要做 5 件事

1. 改动范围是否超出指令
2. 是否改了不该改的文件
3. 接口和数据结构是否保持兼容
4. 异常状态有没有处理
5. 有没有新增难维护的重复逻辑
   可以让 code agent 输出一份改动摘要，包括：

• 这次改动改了哪些文件
• 每个文件改了什么
• 为什么要这样改
• 有哪些潜在风险
• 建议怎么测试
  工程交付不知看结果，也要看可解释性，如果改动说不清影响范围，后面出问题我们很难去定位维护
  开发闭环应该是：
• 先分析需求
• 判断影响范围
• 生成执行指令
• 让 code agent 修改
• Review
• 验收
  让 code agent 从能写代码到能稳定交付，把需求、开发、审核、验收这条链路跑稳
  #学习

谷歌Chrome负责人揭开Vibe Coding幻觉：AI只能帮你写出70%的代码！未来开发者培养方式将变化成三人编程

• 真正的 AI 驱动开发不是“快”，而是有意图的构建
• 如果只是”跟着 vibe 走”，我觉得在创意阶段、原型阶段是可以的，这个阶段更需要发散；但在工程阶段肯定不行，在工程阶段更需要“规范驱动开发”
• 在尝试之前先问自己：“如果把这个问题交给 AI，它会帮我更快解决吗？还是会拖慢我？”即使只是思考这个问题，也能帮助我们更好理解 AI 的边界与潜力
• 大模型的上下文窗口是有限的，这就意味着我们需要：将任务拆解成小的、可验证的块；保持需求清晰，反复迭代；

Medium 上有好多文章都在说公司大规模引入AI编码工具后，会出现软件架构漂移问题，甚至会导致重大生产事故，比如 AWS。去年12月份 AWS 内部 Kiro 在处理 Cost Explorer 服务问题的时候，自主决定“删除并重建”整个生产环境，导致服务中断 13 小时，国内一大堆订单处理受影响。
AI 确实能给开发效率带来显著的提升，但是不是也会带来飞速的架构漂移？OpenClaw 就是一个典型的“几乎全靠 AI 维护”开源项目，它的代码规模也在 AI 快速迭代的情况下快速膨胀，社区也反馈了其很多“局部正确、全局崩坏”的情况。

所以判断力是不是应该成为程序员最核心的能力？

在 AI 时代，比起自己动手写代码，更重要的是能准确判断 AI 做的“对不对”——是不是符合长期架构、业务逻辑、全生命周期成本以及潜在风险
而判断力本质上是大量隐性知识的积累

• 过去踩的坑
• 团队沟通、博弈和权衡的一些实战经验
• 对业务真实痛点、因为成本、扩展性、合规性等的理解

代码可以外包给 AI，但判断没办法外包

#linuxdo

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

反思：如果没有极大发挥 AI 的能力，就只能算是普通程序员 + ai coding 工具协作罢了

#bilibili

对于大模型要有一定理解，不要只把它当成一个黑盒用连最基本的原理都不知道
#linuxdo

车灯只能照亮50米，可车子就是可以跑完全程

post memos test #test