<feed xmlns="http://www.w3.org/2005/Atom"> <id>/</id><title>咏歌与凯旋</title><subtitle>编程、AI与系统思考</subtitle> <updated>2026-04-05T04:24:58+00:00</updated> <author> <name>Liu Zhao</name> <uri>/</uri> </author><link rel="self" type="application/atom+xml" href="/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Liu Zhao </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>吐槽“方法论”</title><link href="/posts/%E6%96%B9%E6%B3%95%E8%AE%BA/" rel="alternate" type="text/html" title="吐槽“方法论”" /><published>2026-03-26T22:13:08+00:00</published> <updated>2026-03-26T22:13:08+00:00</updated> <id>/posts/%E6%96%B9%E6%B3%95%E8%AE%BA/</id> <content type="text/html" src="/posts/%E6%96%B9%E6%B3%95%E8%AE%BA/" /> <author> <name>Liu Zhao</name> </author> <category term="方法论" /> <summary>曾不止一次有人问我你了解方法论吗？对这种没有上下文情境的没头没脑的问题还真让人一时间不知如何回答。 你知道什么方法论吗？ 我当然知道，如果你工作3年以上或多或少大可能都接触过方法论。比如，互联网企业喜欢的敏捷开发，小步快跑，市场验证，干中学；国内软硬件开发大都喜欢华为的IPD；如果你创业做产品，首先考虑PMF，你也知道大部分产品最终都不是最初想的样子，所以要快速犯错，错了就改，改了再犯…，同时现金流重要性是一切，活着比如何活更重要；第一性原理，第二曲线；vibecoding，SDD；计划经济，市场经济，中等收入陷阱，产业升级…，这些都是方法论。 方法论是什么？ 方法论是知识，知识在AI时代的获取成本是0，所以方法论 = 0，啥也不是。 方法论是经验的压缩沉淀，解决某一特定场景的最佳方案，但你学到了方法论就等于你可以做好事情吗？方法论是死的，我们面对的事情却千变万化，你学的方...</summary> </entry> <entry><title>理性看待AI编程</title><link href="/posts/%E7%90%86%E6%80%A7%E7%9C%8B%E5%BE%85AI%E7%BC%96%E7%A8%8B/" rel="alternate" type="text/html" title="理性看待AI编程" /><published>2026-03-26T22:13:08+00:00</published> <updated>2026-03-30T09:59:11+00:00</updated> <id>/posts/%E7%90%86%E6%80%A7%E7%9C%8B%E5%BE%85AI%E7%BC%96%E7%A8%8B/</id> <content type="text/html" src="/posts/%E7%90%86%E6%80%A7%E7%9C%8B%E5%BE%85AI%E7%BC%96%E7%A8%8B/" /> <author> <name>Liu Zhao</name> </author> <category term="vibecoding" /> <summary>我们曾经说过，AI协作编程逐渐被接受，以及SDD理念的推出，这背后是以下三点原因推动： 1.代码生成能力突破，大型模型已经能稳定生成： API CRUD 前后端逻辑 测试代码 2.代码生产成本接近零 3.Repo级理解能力，AI已经可以理解： 整个代码库结构 跨文件依赖 模块关系 同时聒噪的声音也很多，比如：”AI取代研发”，”一些公司只保留初级研发+AI”等等。 现在让我们从三个维度来聊聊，如何理性看待AI编程。 首先有必要认识一下什么是一个工程。 工程的结构：不是线性流程 工程的真实结构 多数人把工程理解成： 需求 → 写代码 → 上线 但真实结构更接近： [问题建模] ↓ [系统结构设计] ↓ [实现（代码生成）] ↓ [运行态控制] ↓ [反馈 → 重新建模] 1. 建模层（Modeling）👉 决定问...</summary> </entry> <entry><title>为什么 AI 协作开发需要项目上下文系统</title><link href="/posts/why-ai-context-system/" rel="alternate" type="text/html" title="为什么 AI 协作开发需要项目上下文系统" /><published>2026-03-24T22:13:08+00:00</published> <updated>2026-03-25T06:05:27+00:00</updated> <id>/posts/why-ai-context-system/</id> <content type="text/html" src="/posts/why-ai-context-system/" /> <author> <name>Liu Zhao</name> </author> <category term="vibecoding" /> <category term="sdd" /> <category term="context" /> <summary>1. 目标背景 这份文档想聊的是，在 AI 协作开发的过程中，为什么我们有必要把 VibeCoding 和 SDD 这些做法，从“经验技巧”慢慢沉淀成一套更成形的文档系统。本质上，这也是在尝试把一些最佳实践和规范，真正产品化出来。 它想回答两个很实际的问题： 为什么 AI 协作开发会需要一套项目上下文系统 为什么“持续维护”这件事，不是额外负担，反而是这套系统能成立的前提 这不是一份模板说明，也不是某个具体产品的使用指南，更多是一份理念层面的梳理。 它想解释的是：在 AI 越来越多参与开发的今天，我们怎么把 VibeCoding 和 SDD，从“靠个人经验”的状态，变成一套可操作、可维护、也能复用的方法。 2. 问题不是“缺文档”，而是缺可依赖的上下文 很多项目其实并不缺文档。 更常见的情况是： README 有，但没有一个真正稳定的入口 PR...</summary> </entry> <entry><title>openclaw使用反馈</title><link href="/posts/openclaw%E4%BD%BF%E7%94%A8%E5%8F%8D%E9%A6%88/" rel="alternate" type="text/html" title="openclaw使用反馈" /><published>2026-03-19T22:13:08+00:00</published> <updated>2026-03-24T00:44:17+00:00</updated> <id>/posts/openclaw%E4%BD%BF%E7%94%A8%E5%8F%8D%E9%A6%88/</id> <content type="text/html" src="/posts/openclaw%E4%BD%BF%E7%94%A8%E5%8F%8D%E9%A6%88/" /> <author> <name>Liu Zhao</name> </author> <category term="agent" /> <summary>体验基于版本OpenClaw 2026.3.13 (61d171a) openclaw使用已经有数天，期间我把openclaw当作个人助手使用，并对它有一定期望，主要聚焦于以下几件事情： 1.性格定义： 我给它设定了形象，性格。 我希望它带着我设定的性格，主要表现在沟通方式上，因为是个人助手，性格会让沟通这件事情很有趣。 2.每日任务： 每天弱提醒我阅读一本书，并与我探讨某章节内容。 每天定时发送小红书内容，帮我运营一个账号，图片+文本。 每天定时整理并发送某一个领域的知识总结，消息推送+保存notion中。 3.记忆维护原则： 鉴于共同记忆维护在记忆文件中，期间我多次对memory.md进行了优化，文章后面会提到做了哪些优化。 以上几件事情看起来不是很复杂，但使用过程体验令人几度要放弃。 一部分是模型能力差异，另一部分我认为是缺乏记忆机制与上下文管...</summary> </entry> <entry><title>提示词工程</title><link href="/posts/%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B%E7%9A%84%E6%9C%AC%E8%B4%A8/" rel="alternate" type="text/html" title="提示词工程" /><published>2026-03-16T22:13:08+00:00</published> <updated>2026-03-24T00:38:34+00:00</updated> <id>/posts/%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B%E7%9A%84%E6%9C%AC%E8%B4%A8/</id> <content type="text/html" src="/posts/%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B%E7%9A%84%E6%9C%AC%E8%B4%A8/" /> <author> <name>Liu Zhao</name> </author> <category term="AI" /> <summary>大多数人在优化“表达”，而不是在设计“控制系统” 你在“生成 prompt”，而不是“写 prompt” 先写控制信号再“翻译”为自然语言” 提示词技巧 → 在语言层面影响模型 控制信号 → 在决策层面约束模型</summary> </entry> </feed>
