一个模型回答得“像专家”,不代表它理解了你的上下文。真正可用的提示词,通常先定义边界,再要求输出。
主题索引
这不是分类目录,更像我长期反复观察的几个问题域。
文章
较完整的长文,围绕 AI 产品、技术判断、知识工作流与个人成长展开。每篇文章都尽量回答一个具体问题。
笔记
短一些的观察,可能来自代码、会议、书、一次失败的沟通,或者某个还没有长成文章的问题。
产品里的高级感很多时候不是视觉效果,而是少一次打断、少一个不必要的选择、少一段解释成本。
如果一个需求只能通过很长的文档解释清楚,它大概率还没有进入可设计状态。
学习工具不应该成为逃避输出的方式。输入系统的目标,是让你更快面对一个具体判断。
工程判断的核心不是“能不能做”,而是“这个复杂度会在什么时候、以什么方式回头找你”。
复盘不是重新责备自己,而是把下一次可以提前识别的信号写下来。
项目
一些围绕 AI、写作、知识管理与设计系统的小项目。这里记录结果,也记录过程中被验证或推翻的判断。
书单
不是完整书评,而是那些长期改变我看待产品、技术、写作和个人成长方式的书。
《设计心理学》
提醒我:好设计首先是减少误解,而不是增加表现力。
《程序员修炼之道》
关于工程职业判断的很多建议,放到 AI 时代仍然成立。
《卡片笔记写作法》
有帮助的不是工具本身,而是持续把问题外化的习惯。
《原则》
我不完全认同其中所有判断,但它展示了复盘系统如何被结构化。
《创新者的窘境》
很多技术变化不是突然替代,而是先在边缘场景里积累优势。
《写作是最好的自我投资》
表达不是输出的最后一步,而是整理判断的过程。
关于
我关注的是 AI 的能力边界,也关心人如何利用工具而不是成为其附庸
我长期关注的事情
不是职业标签,而是反复出现的问题。
AI 产品如何建立信任
包括解释、可控性、失败提示、引用来源,以及人如何在自动化流程中保留判断权。
知识工作者如何管理输入
不是收藏更多内容,而是把问题、材料和决策连接成可复用的系统。
个人成长里的慢变量
表达、复盘、判断力和节奏管理,这些东西不容易自动化,却长期决定上限。
把 AI 当作一面镜子,而不是一台神谕机器
对程序员、大学生和产品经理来说,真正重要的不是“AI 会不会替代我”,而是它能不能逼我们更清楚地提出问题、看见盲点,并把模糊的想法整理成可行动的下一步。
我第一次意识到 AI 对个人成长的影响,不是在它写出一段漂亮代码的时候,而是在它追问我“你真正想优化的指标是什么”的时候。那一刻我发现,自己并不是缺少答案,而是太习惯把半成形的焦虑包装成一个看似专业的问题。
这也是很多人使用 AI 时最容易错过的部分:我们把它当作搜索框、实习生、代码补全器,甚至是某种廉价顾问,却很少把它当作一面能反射思考质量的镜子。它当然会犯错,会编造,会顺着你的话讲下去。但恰恰因为它反馈得足够快,我们才有机会更频繁地观察自己如何提问。
01 / 问题的质量,决定了工具的上限
对程序员来说,AI 可以帮你写样板代码、解释报错、生成测试用例。但如果你不知道系统的边界在哪里,不知道哪部分逻辑必须保持可读,不知道性能瓶颈是否真的存在,那么 AI 只会把不确定性放大成更多看似完整的文件。
对产品经理来说也是一样。让 AI “帮我设计一个增长方案”往往得到的是一组正确但无用的常识;但如果你告诉它用户分层、当前转化漏斗、实验约束和不可触碰的品牌边界,它就会变成一个不错的推演伙伴。
02 / 把“求答案”改成“做校准”
我更喜欢把一次 AI 对话看作三轮校准。第一轮是倾倒,把脑子里混乱的材料全部放出来;第二轮是归纳,请它找出结构、矛盾和缺口;第三轮才是生成,让它基于新的结构给出方案。
Note 一个简单的判断标准是:如果你把同一个问题交给不同的人类同事,他们也只能给出泛泛建议,那么问题本身就还没有被定义好。
这种使用方式特别适合大学生。因为学习的核心不是囤积资料,而是建立自己的判断坐标。你可以让 AI 扮演反方,质疑你的论文论点;也可以让它扮演面试官,追问项目经历里最薄弱的地方。
03 / 一个更可靠的个人工作流
我现在会把 AI 放进日常工作流中,但只给它三个明确职责:压缩信息、暴露假设、生成备选。压缩信息,是把会议记录、论文摘要、用户反馈变成可比较的结构;暴露假设,是追问方案背后的前提是否成立;生成备选,则是在方向已经确定后,扩展表达、命名或界面状态。
- **先写自己的判断。**在打开 AI 之前,先用三句话写下你认为问题的关键。
- **要求它指出不确定性。**不要只问“怎么做”,要问“这个方案最可能错在哪里”。
- **保留人工决策点。**凡是涉及取舍、价值排序、用户伤害和长期成本的决定,都不应该交给模型自动完成。
04 / 最后,别把工具崇拜成信仰
我们应该拥抱 AI,但不必崇拜它。它擅长模式,擅长语言,擅长把已有材料重新排列;而人仍然要负责经验、伦理、语境和品味。
当你下一次打开对话框时,可以先不急着问答案。试着把问题写得更诚实一点,把限制写得更具体一点,把你自己的判断也放进去。然后观察它如何回应。
为什么好产品总是先减少一步
这篇文章页沿用同一套文章模板。正式内容可以直接替换到 `.prose` 容器中。
很多产品的高级感,不来自更多功能,而来自更少的解释成本。减少一步,不是删减价值,而是删掉用户不该承担的认知负担。
你可以把这里替换成完整正文;标题、段落、注释、引用、图示都复用同一套组件。
给大学生的第二大脑使用指南
不要收集更多资料,而是建立能反复调用的个人问题库。
第二大脑不是收藏夹,而是一套让问题持续生长的系统。资料只有在被问题调用时,才真正进入你的知识结构。
这个页面同样复用文章页结构,方便后续扩展为完整长文。
程序员如何训练产品直觉
从边界条件、失败路径和用户语言开始,而不是从功能列表开始。
工程师理解产品,不需要先变成另一个角色。很多产品判断都藏在边界条件、异常路径和用户真实表达里。
这个页面保留为完整站点的文章模板示例。