MoreRSS

site iconShadow Walker | 松烟阁修改

Where other men are limited by morality or law, remember, everything is permitted. I walk in the darkness to serve the light.
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Shadow Walker | 松烟阁的 RSS 预览

在乌龟追上来之前

2025-10-03 19:50:24

CTA Image

E41 孟岩对话阿娇:我的另一面,也想被注视和欣赏

Listen

播客对谈刚开始(22:42)的一段对话,跟去年的付航给我的感受很相似:

孟岩:我还是会好奇那些,为什么一个人可以变成这样的,可以去解决任何问题的人
阿娇:我没有,我没有

阿娇说「我没有」的时候,喉咙是略带干涩的,一段明显的停顿之后再次强调了一下「我没有」。第一次听这一段的时候,我正好在开车通勤,当时鼻子一酸,到现在我还是不知道用什么语言描述我当时内心的感受。

这期播客中有非常多的停顿,孟岩的、阿娇的,有各自一度语塞的、有阿娇身体不适的杂音、有喝水的咕噜声等等,在追求严谨、品质、精致的播客里这无疑是惨不忍睹的。但是我很珍惜这一期播客,小宇宙里唯一收藏的就是它了,相比当下社交媒体为大众营造的美好、精致、暖心、振奋,它足够真实,还原了这个世界本来的样子,可以有口癖、有粗口、有空白。

理解阿娇

这期播客我听了很多遍,因为心境不同,其实前几遍的时候,我并不太理解阿娇和孟岩对谈的一些话。

「这几个月,我反反复复在想,也反反复复有人在聊的东西——为什么死亡已经迫在眉睫,看起来这世间一切都即将与我无关,可欲望没有退潮?为什么我对自己的诸多想象,我的诸多理想主义,我的追求,我的欲念,它未曾消退?我以为会一切返璞归真,去伪存真,最后只剩一两件要紧的事,一两个要紧的人,但是偏偏不,我还是有那么多想做的事情。」

「真正的外部评价无法刺穿的屏障,是只有我自己能刺穿的。」

「正是因为我有很多想说的,那不说也好,不说也好。把那些话留着,让我自己去消化,然后把那些表达欲留着,让我自己去消化,我们之间留一些无人知晓的留白。
可能在你以后几十年的生命里,我不知道你会不会再想起我,(可能)某一次晚霞,或是某一次海口的落日,会让你再想起我这个人,然后你再回味时,你回味起的,也许就是我想跟你说的话。」

阿娇期待别人的注视,特别是与高手的对谈,但是她不喜欢别人用标签的滤镜来关注她,阿娇的心境与我过往写的一篇博文不谋而合(如何减少标签对自己分享带来的压力)。作为一个被医生预测只能活到今年八月份的晚期病人,她自己都没法预测下一周能否「完美交付」,所以她更加希望珍惜自己每次的「在场」,我想当下对阿娇而言Everything matters,她渴望的是被看见和尊重的专业能力、平等的智识交流、完整且立体的女性。

所以孟岩提到的「你要是能够有钱做投资,一定会是一个很好的投资人」,其实说明他是没有真正理解傲娇,还是带着「柱子哥」的标签来看待阿娇。我也能理解孟岩在问阿娇「我们交流了之后还觉得我是高手吗?」,阿娇没有正面的回答,但我觉得已经给出答案了,一个被阿娇认为非常charming、智慧的孟岩也并没有真正的看到懂得如何注视阿娇。阿娇追求的是在命运的巨大不确定性面前,夺回对自己生命叙事的定义权,其实在跟孟岩的交流中就已经给出答案了:「我,阿娇,首先是一个有能力的专业人士,一个热爱生活的独立女性,其次,才是一个病人。」

理解孟岩

这期播客里孟岩像是一个客人,言语之间充满了谨慎,他的语调与提问,随时在自我提醒:这一步会不会冒犯到的。那份小心并不傲慢冷漠,反而带着温度——一种想要守护的敬意。

我能理解,孟岩的谨慎来自悲悯以及对话题重量的清醒认知,更是来自健康者难以跨越的距离感。阿娇的坦然,并不是无能为力的自我安慰,而是带着遗憾地一次次与死亡的直面、与痛苦的缠斗。她已把死亡当作生活里不可回避的「考题」,用一种近乎平常心的姿态谈论它。

我能理解也更感谢孟岩,在这期的对谈没有运用任何技巧和引导(这是孟岩擅长的,却是对阿娇的误解和亵渎),孟岩没有让他们的对话陷入对苦难的消费,也没有流于空洞的正能量,他守住了边界与尊严,坦然赋予了厚度与真实。那些停顿、噪点与呼吸,比流畅的表达更有力量——它们让人听见了生命最真实的质感。

理解自己

  • 不能在场 vs. 不能上场,哪个更让你痛苦?不能上场是命运的安排,不能在场是心的背叛。人在却心不在,比缺席更残酷。
  • 没有过去 vs. 没有未来,哪个更让你不能接受?失去过去是失忆,失去未来是虚无。我更怕门被锁死而不是记忆被抹去。
  • 从未在一起 vs. 最终没在一起,哪个更让你遗憾?最终没在一起至少有过印证,从未在一起只剩无尽的“假如”。空白比断裂更让人困在迷宫。

我重复听了很多遍这期播客,阿娇让我想到了自己的一位远赴异国的老友阿楠,她们两个给我的感受很像,聪明能干、倔强要强、直面挑战和对抗。也不知道经历了生活的磨砺之后,现在的老友有没有改变,不过我知道她现在很开心很幸福,这是让我觉得好的地方。至少,在生命体验的角度阿娇跟阿楠是不一样的,我的朋友是无比幸运且幸福的。

我的笔触在高维空间独一无二

2025-09-14 14:57:24

最近在复盘松烟阁管理的时候,我用朱雀检测测试了一下最近的两篇博文,结果还挺精确:

两篇文档都是出自我手,我非常清楚其中的细节以及写作的过程,第一篇是我纯手写,第二篇表格部分是我用Gemini生成的,由此可以见检测结果与事实完全正确。

自从AI能够生成高质量内容就是,创作者群里就一种声音表达自己对内容的洁癖,比较激进的甚至会表达类似「只要是AI生成的内容就不愿意付出精力和时间去阅读」。我一直努力在克制自己创作内容中掺入AI生成的部分,不过确实要承认在结构化思考和表达上AI更优秀,起码比我自己的表现是要好的,慢慢地我可以接受自己为文章内容提供灵魂,而AI为我的文章内容提供装饰品。

AI正在深刻的改变我们生活的方方面面,我想写作上就是这样的,而怎么控制好以及怎么区分是否来自AI,这就是我今后要逐步积累和锻炼的能力。

换个视角,其实这两篇检测报告也从另一个方面证实了一个AI和人是有区别的。

AIGC的本质就是将人类语言通过分词进行向量化,通过神经网络将文本、语言问题转换成了矩阵运算的问题,无论是余弦相似度或者是欧几里得距离表示生成内容与输入内容的相关性,这些向量都是人类语言在高维空间的映射表示。

而朱雀检测能够通过大模型区分出人写的和AI生成的,其实意味着人自己写的东西在高维空间是有非常显著特征的,只是生活中三维空间的人普遍没办法感知到而已。朱雀检测其实就量化的证明了,在某个未知的高维空间里面可以非常清晰地区分人写的内容与AI生成的内容的。

从这个角度来看,我一直输出写作是有意义的,因为数学说明了在这个时空的某个维度我的内容具备了AI没法取代我的特征(至少目前为止AI做不到取代我),这样的经历让重新对人的创作有了信心。做一个坚定的人类相信者,拥抱和享受AI给我们带来的变化吧。

最后,致敬那些一直在坚持自己博客的朋友,以此共勉!

大厂生存实录:从老板的“屎”论,谈谈如何去除内容的“AI味”

2025-09-07 17:26:45

背景

最近职场槽点真的有点多,这周开会的时候大老板在质疑AI投入的必要性问题,其中有一句我个人觉得可以列入年度金句了:“没有用AI之前,xxx问题有什么影响?我看大家都觉得没什么问题都能扛得住,我承认它是「屎」,但是不是大家也能忍着,也没出什么事......”

说这句话是基于大老板对于当前AI的认识:

  • 直接让大模型分析一些业务问题,它给出的回答看上去像模像样,将来80%的Agent会被大模型内化掉;
  • 现在Agent的构建很方便也很廉价,甚至外包都能做;
  • 目前Agent在内部的应用碰到了非常强烈的幻觉问题,没法立竿见影地产生业务价值;
  • 面对技术趋势,一群程序员是为了做AI而做AI;

在大厂环境中,上面提到的大老板的这些潜台词无可厚非,我不打算做更多的吐槽,我打算思考一个问题:怎么判断一段内容是AI生成的,它的特点和根因是什么。

只有了解通用大模型生成内容的原理以及特点,才能继续评价Agent的价值和发展,这个问题留待下一篇职场生存实录文章探讨吧。

内容的「AI味」

读一段文字,你有没有过那种感觉?哪儿都对,就是心里不得劲,通顺有逻辑,但就是没人味儿。当时我还纳闷,后来才反应过来,这就是所谓的“AI味”。

一开始我也觉得,是AI还不够牛,等它再进化几代就好了。利用周末的时间我研究了一下这个问题,我感觉这根本不是技术问题,换言之模型进化未必能解。AI的本质是个超级厉害的统计学模型能算出哪个词后面跟哪个词的概率最高——它知道“心碎”这个词旁边经常出现“眼泪”和“夜晚”——但它跟人不一样没有自己的「心」,所以它根本不知道心碎是种什么感觉,这些具身数据的缺失注定它没办法真正“体验”,就像一个人照着菜谱念菜名,词儿都对但没有锅气。

“AI味”的特点

为了可以识别“AI味”,我觉得可以从结构、语言、语调和内容深度四个维度来分析“AI”内容的特点:

类别 具体标志 示例
结构 公式化的文章结构 严格遵循“引言-论点1-论点2-论点3-结论”的模板。
冗余的总结 在文章结尾反复用不同措辞总结相同的内容。
词汇与短语 重复的过渡短语 频繁使用“总而言之”、“此外”、“值得注意的是”等。
通用、空洞的词汇 滥用“变革者”、“前所未有的”、“至关重要”等词语。
语调与声音 过度的中立性 对有争议的话题采取绝对中立,缺乏明确立场。
缺乏个人声音 语调统一、平淡,听起来不像任何一个特定的人。
内容与实质 缺少个人轶事 仅陈述事实和数据,没有个人故事或案例来支撑。
表面化的分析 解释“是什么”,但很少深入探讨“为什么”或“如何”。

“AI味”的原理

生成式大模型的核心运作机制是基于统计概率预测下一个最可能出现的词或短语,而非真正的理解。这个过程天然地导向一种“向平均值回归”(regression to the mean)的趋势。因为模型旨在生成最“安全”、最“普遍”的输出,所以它会频繁地使用那些在训练语料库中统计上最常见的通用短语和陈词滥调 。它擅长的是复制,而非真正的原创 。

同时,因为缺乏人生活中接触的超越文本数据之外的共享语境数据,大模型的具身认知(embodied cognition)是缺失的,AI无法捕捉情感的细腻纹理和道德的复杂性,无法理解讽刺、反语或微妙的文化隐喻的原因就在于此。

大模型的架构和训练机制引发的“浅输入,浅输出”即奖励机制导致大模型追求平均和正确,也就是正确的废话,这也侧面说明了AI输出的质量与输入的质量、上下文深度直接相关 。一个笼统的提示词,如“写一篇关于人工智能的博客”,没有提供任何具体背景,迫使AI只能从其训练数据中最通用、最宽泛的部分提取信息 。

这样“AI味”的原理就清晰了:浅层输入导致AI调用通用模式,表现为刻板结构和通用短语,最终产出固定模式的文本也就是“AI味”。

如何用prompt去“AI”味

宝玉老师推荐的怎么用大模型去掉“AI”味,本质上就是“让大模型主动露拙,模仿人的随机性”,具体prompt如下:

1. 用词与句式
- 70% 句子长度 < 18 词;偶尔插入 < 6 词的独立短句。
- 使用常见口语连接:and, but, so, anyway, you know.
- 每段至少包含一个具象细节(气味、手感、具体对象)。

2. 叙事与结构
- 采用第一人称或“我/我们”叙述,加入个人小片段(真实或拟真)。
- 不做完整封闭结论,最后一段留一点未决疑问。

3. 语用特征
- 保留一两处自我否定或转折(“其实…但回头想想…”)。
- 允许一两个轻微重复或改写,而不影响理解。

1. 技术采样参数(如需)
- temperature 0.9–1.1;top_p 0.9;top_k 40–60。
- frequency_penalty 0.3;presence_penalty 0.6。
  
以下是一些范文参考:
{text}

最后我把上面的思考内容喂给NotebookLM,让它给我一个关于“AI味”的Overview:

0:00
/7:30

大厂生存实录之为什么是我做

2025-08-31 22:21:10

🍿
文章想以《浪浪山小妖怪》里的几句台词作为开篇
熊教头:“小的们,你们看好了,这弓,要这么拉。你们还得多练呐,不然,怎么在浪浪山干活啊!”;
狼总管:“大王说,要突出一个‘陷’字。”

工作当中的烦恼真的让人无力和恼怒,在做的一个CVE相关的AI项目,在误报阶段已经有60-70%的CVE可以被AI处理,准确率也达到了90%,接下来阶段就是对非误报的CVE进行安全风险评估,包括安全技术分析、攻击向量模拟、可利用性评估、修复难易评估、Patch修复、发布Errata,这里涉及到的数据、工作量极其繁杂,一个40+人的团队在投入但是人力上还是捉襟见肘。Leader决定拉起一个「数字员工」的项目,将AI引入全部的CVE处理流程,用来提升CVE处理的效率解决人力的问题。

我们作为安全团队,除了负责AI Infra的建设之外,要做的一个事情就是为CVE漏洞给出安全风险评估,包括安全技术性分析、攻击向量模拟甚至CVE利用的PoC等等,这里面涉及到很多安全数据和模型,发挥AI的能力是比较自然的思路,于是大家一致同意把这个纳入到上面提到的「数字员工」项目中。

公司将AI作为公司级别的战略,所以AI应用在公司内部属于百花齐放的阶段,跟创业类似的,周边团队在开发AI应用的时候碰到Agent幻觉等问题,导致在收益上比较微薄也就是常说的ROI不高,但也确实的减少了几乎一半的工作量。面对这种经验,Leader们泛起嘀咕——现阶段大力投入AI是不是会收益微薄甚至项目失败,不妨等技术成熟一点再加大投入。于是Leader在项目讨论会上,一直push我们要求给数据、给指标,一个没有跑起来的项目当然没有符合老板预期的数据和指标,甚至连数据打标点都还在设计中,可想而知项目的推进阻力会如何之大。

这期间还发生一个让我无言以对的事情,我的直系Leader问我「CVE这么多繁琐的流程,如果我跳过所有的前序步骤,来一个CVE我就用AI merge修复patch这样是不是也可以?」。面对一个企业级的操作系统产品,这个问题有很多角度来分析和论述:

  • 修复patch来源考虑,大约只有30%左右的CVE才有上游patch
  • AI修复CVE代码的能力问题,复杂patch人肉cherry-pick的时候都会失败何况AI
  • AI合入patch的效率和成本问题,面对每个月1000+的CVE修复(一个CVE修复时间按照8个小时算,那是15人月工作量,换算成AI Token应该有千万量级资金开销了)
  • 直接合入patch代码引入的安全性问题,patch是否修复CVE,是否引入新的风险,这些不分析无法判断
  • 直接合入patch代码引入的稳定性问题,变更意味着稳定性问题,看看Debian操作系统的版本管理就知道了

面对革命性的技术浪潮,到底是想清楚再做还是先做然后调整呢?我的理念是「想都是问题,做才是答案」,同样都是付出成本与代价,与其在想这件事情上浪费人力物力,不如把成本放在做这件事情。想出一个 90 分的方案再去执行,相比一个 60 分的方案加后续再打磨完善,后者更能在过程过获得做事的成就感,形成一个输入和输出的正循环。

抛开理性分析,安全团队不是应该专注于自己领域的问题的研究和解决吗?把自己的Ego和Scope扩展到这么大,是不是太把自己当回事了,大厂这样的巨无霸面前不会真由基层员工来掌控方向的,都是螺丝钉就别给自己加戏了。大厂这样环境给人太多枷锁了,一直在被要求回答:我是谁,我在做什么,我为什么要做,为什么是我做,Blablabla……作为小团队的Leader没有这样清醒的意识,真的会「累死三军」

这篇文章没什么总结更没什么思考,只是感慨跟我类似的这些困在大厂里的「牛马」,慢慢的你会越来越清醒的意识到一个道理:“在大厂永远不会得到精神自由”!

Cursor与Vibe Coding

2025-08-09 21:30:37

Vibe Coding以及八卦

简单总结Vibe Coding:人利用AI生成代码完成大部分的软件开发任务。

我个人理解Vibe Coding的本质就是开发工作中的一种新的协作关系 —— 人专注于差异性工作,把能交给大模型做的工作尽量交给它去完成,充分发挥AI的可塑性、高效性等。

随着大模型底层基础能力的飞速迭代(例如Qwen3-Coder),AI的能力范畴正在变得越来越大,Vibe Coding的发展趋势就是自底向上蚕食程序员的工作范畴。

Vibe Coding的分层架构(理想)

以Cursor和Claude Code为代表Vibe Coding工具正在快速迭代,Vibe Coding的架构是时刻在演进和变化,我根据自己的理解比较理想化给出Vibe Coding的分层架构,与上面发展趋势图相对应,Vibe Coding发展到最后就是这张图只剩下蓝色框框没有其他颜色🥳。

Vibe Coding的八卦

关于Vibe coding的八卦,一图胜千文,其实目的还是想让好奇AI Assistant Coding的人知道它的优缺点,以及需要注意的事项。

Vibe Coding技术研究

AI Code Agent工作流

我总结了主流的几个AI Code Agent的架构:

1. Cursor Agent工作流
2. RooCode Agent工作流
3. Cline Agent工作流

综合来看,当下AI Code Agent的技术架构基本上都是类似的,主要的差异就是工具、策略等方面选择的差异。

AI Code Agent技术架构

以Cline架构为例对AI Code Agent架构进行管中窥豹

除了基础模型造成的差异之外,Cline建立的AI Coding的差异化竞争力主要在:

  1. Human in the loop: 这是Cline最根本的架构原则。通过要求用户对所有关键操作进行审批,它在强大的自主能力和专业开发所需的安全可控性之间取得了务实的平衡,使其成为可以信赖的工具;
  2. MCP实现的开放扩展性: Cline没有选择构建一个封闭的、专有的工具生态,而是全面拥抱了开放标准MCP。这不仅为其带来了无限的扩展能力,更使其成为一个能够自我完善、与社区共同成长的平台;
  3. 混合式上下文管理: 结合自动化分析和用户精确引导的上下文管理策略,是Cline能够有效处理大型复杂代码库的关键。它承认AI的局限性,并巧妙地将人类的领域知识融入到人机交互的循环中;
  4. 工具生态:代码理解、codebase index、AST、diff_apply等代码相关的工具生态支持Cline能够高效和准确的完成任务,同时支持可扩展性;
  5. 模型无关的灵活性: 通过稳健的 LLM 抽象层,Cline避免了对任何单一模型提供商的深度绑定。这使用户可以根据任务需求、成本预算和性能表现,自由选择最合适的AI“引擎”;

我们更进一步来拆解这些优势:

竞争力项目 Cline Cursor RooCode
Human in the loop
MCP生态支持
工具生态 AST RAG AST + RAG
混合上下文管理 Context Management Automated Context Management + Context Priority Management Intelligent Context Condensing
Agentic AI Model
Model apply edit 小模型

AI Code在卷哪些技术一目了然。

Vibe Coding应用

Vibe Coding 大致上有两种使用方法:

  1. 我需要个xxx(我需要xxx功能),帮我实现一下,然后一直retry;
  2. 我按照方案和架构设计原子化Vibe Coding任务,然后提供任务必要的信息,然后交给AI实现;

实践中,我发现方法1可以极大释放人力,有的时候AI给出的结果超出预期,唯一存在的问题就是人对于代码的信任度。方法2效率提升不如方法1,但是基本的代码实现以及项目进展情况人能够掌控,能够有效的避免AI Coding的几个问题:

  • 偷懒(例如,几次测试通不过直接在测试代码pass来绕过失败的case);
  • 用力过猛(例如,有现成的算法实现还自己重复实现一套);
  • 幻觉(例如,判断条件弄反了等);

基于上述经验,我对Vibe coding的采取的是不信任的态度,原子化任务保证我能够review检查代码(神仙也很难在2万行代码的PR里面准确挑出2-3个bug)。同时,如果是比较明确的任务并且已经有参考(例如已经有sqlite实现了,让AI完成mysql的实现)我就会采用方法1来提升效率。

另外,还有一种方式(我使用相对较少)—— 结对编程的方式,即向AI描述问题或者需求,然后AI规划方案,人来修改或者补充形成 todo list(plan),然后由AI实现。

最后,总结一下Vibe Coding的个人思考:想写一个demo直接扔给AI自动完成,当下的AI已经能够保证试错成本和效率了。想写一个生产使用的软件,自己把控方案设计和技术架构让Vibe coding作为帮助生成代码的工具,同时对Vibe coding始终抱着不信任的态度,时时review、处处检查。

几个重要原则

由于每个人使用AI Code工具以及编程习惯都不一样,所以有一些关键原则是需要注意的,其他可以自由发挥。

  • 最重要的原则,Curosr能写出符合要求的好代码的前提是它有足够的上下文,包括:项目、需求、架构、技术栈、编程约定等等;
  • 清晰的文档和注释,让Cursor获取更多的上下文;
  • AI更擅长修改和优化,新创造有一定的随机性,随着模型增强会改善;
  • 当下的Code Agent已经足够好了,特别是在Cursor,Cline等成熟产品中prompt可以更加自然语言些,类似「你是个xxx专家」这类激活专家系统的方式可以放弃了,省钱还省时间;
  • prompt engineering技巧的掌握和运用还是要持续升级,例如最近跟着Manus学会的response prefill技巧,使用<|im_start|>assistant<tool_call>{"name": "xxx"来控制工具调用的模式(自动、必需、指定等);
  • 有规划的拆分原子任务,一次只做一件事,有助于代码的准确性和可靠性;

几个重要概念

Agent/Chat/Tab

能够跨多个文件读取和修改代码的 AI。用自然语言描述更改,Agent 会执行这些更改。

Rules

定义 AI 行为的自定义指令。设置编码标准、框架偏好和项目特定约定。

Memory

持久存储项目上下文和过往对话中的决策。在未来的交互中自动引用。

codebase index/graph

对代码库进行语义分析。支持代码搜索、引用查找和上下文感知建议。

context

在代码生成过程中提供给 AI 模型的信息。包括文件、符号和对话历史。

基于Cursor的Vibe Coding

1. Cursor Rule设置

Rule的设置是为了让Cursor了解项目结构以及开发约定,包括:

  • 编码关于代码库的领域特定知识
  • 自动化项目特定的工作流程或模板
  • 标准化样式或架构决策

Rule编写时应该注意:

  • 保持规则在500行以内
  • 将大型规则拆分为多个可组合的规则
  • 提供具体的示例或引用文件
  • 避免模糊的指导。编写规则时要像清晰的内部文档一样
  • 在聊天中重复提示时重用规则

rules 结构示例如下图所示

另外一种Rule设置方法(来自Cline),Task Manager + Todo List的方式管理active context:

Task Manager的方式使用AI Code工具是比较进阶的使用方式,项目开发周期的缘故我还没生产实际中使用过,后续再研究和分享。目前这块有一些比较不错的实践经验可以参考:

2. 文档更新

我会在项目的docs目录中放置所有的项目相关的问题,包括技术选型、架构设计、模块说明、部署架构、使用手册等等,这样可以让人和AI都能够及时了解项目详细情况,一般修复问题或者新增feature的时候,我会将对应的文档添加到上下文中(@docs/xxx.md),帮着Agent能够更好的完成任务。

随着项目迭代和演进文档需要及时更新,不然会对AI形成误导导致无法正确地完成任务,所以我会形成固定的文档更新工作流。

flowchart TD Start([Start]) End([End]) Agent[Task Auto Trigger]:::redClass Developer[Triggered by Hand]:::blueClass Task[Document Update Process] subgraph AI-Process direction LR P1[Review Files] P2[Current State] P3[Clarify Steps] P4[Documents Change] P1 --> P2 --> P3 --> P4 end subgraph Review-Change Review[Developer Docs Change Review] Review -->| review ok? |Review Review --> Apply[Merge Changes] end Start --> Agent Start --> Developer Agent --> Task Developer --> Task Task --> AI-Process AI-Process --> Review-Change Review-Change --> End classDef redClass fill:#ffcd70,stroke:#333,stroke-width:2px; classDef blueClass fill:#97fcf9,stroke:#333,stroke-width:2px;

3. Cursor四大使用场景

  1. 功能实现,先给样例再给出功能实现的要求以及项目上下文
  2. 测试代码,给出测试规划并要求测试要求
  3. 修复问题,给出问题描述以及关键上下文
  4. 比较方案,对于无法很好解决的问题让Cursor给出方案以及比较

References

  1. Taskmaster AI - The PM for your AI agent
  2. Shrimp Task Manager - 為AI編程助手提供結構化任務管理的智能系統
  3. Waterfall, Agile, And AI: The Evolution Of Development · ProgrammerHumor.io
  4. OAuth provider library for Cloudflare Workers|一个由Claude实现的代码库
  5. cline-doesnt-index-your-codebase-no-rag-activity | LinkedIn

日本游记 —— 大阪京都

2025-08-02 21:48:45

趁着暑假,跟家人一起去大阪和京都,有一些见闻和感受想记录一下

有这样一句话「你不买东西,去大阪干吗?」,大阪的心斋桥是一个购物的天堂,这里有性价比极高的药妆店,数码店,让我这种物欲很低的人都忍不住买买买。

不得不说心斋桥是一个可以放大人物欲的地方。

还有一个关于物的感受,除了经常听说的精致、匠心之外,我在大阪生活方方面面碰到的物品,无论是菜单、点餐机器、硬币机器、地铁JR闸机等等,都有很重的使用痕迹,大多磨损很厉害,但是无一不是设计精巧、指示明晰、使用顺畅。这些物品极大释放了人力,这一切物品和工具让我看到了一些视人为人的意境,在这里物最重要的工具属性得到了充分发挥,人在物的帮助下能够悠闲且毫无顾忌的席地而坐,饮一杯自动贩卖机啤酒。

留心查找这些物品的信息,其中不乏美的、格力等产自中国的东西。很可惜,在国内难得看到这样视物为物、视人为人的松弛和安逸。

在来日本之前,对日本的「跪式服务」早有耳闻,冷漠、社畜甚至变态也国内也多有提及,但是他们又能说出「山川异域,风月同天」这种令人神往之语,所以我对他们的人都很好奇,这次旅游用心观察了一下。
日本人干活总是有种不急不慢的感觉,刚到大阪的第一天我们就奔着一家很有名神户和牛店去了,因为没有预约防止没有位置,我们5点不到就到店里了,整个店很小巧,最多能容纳6个人,我们在翻看菜单的时候一个刚刚来上班的店员,推门而入的时候拖着长长尾音跟店里忙碌的师傅打招呼“はい~~”,左右摇晃的双肩包,踮着脚从我身后欢快走过。在帮我们摆放和牛的时候,专注、细腻,wasabi的形状都特意调整好……

地铁上,偶尔看到男生打扮得很日系动漫,不多但挺精致,我做公共交通期间之间到过一次,打扮很像进击的巨人里面的艾伦,上衣的装饰以及裤子镂空的细节都能看出非常精致用心(P.S. 日本人对在公共空间拍照时很敏感的,所以只能用苍白的语言形容这种精致了)。


大部分日本女生的装束都是可爱风精致感觉,年轻女生一般是前面刘海微微卷一下,打扮很精致,脸部会抹点儿腮红,除了这个印象其他跟国内其实差不多。

图片源自X:BNT

还有一件关于人的事情值得分享,在大阪我发现了一家我超级喜欢的咖啡屋,早上10点的时候可以见到各式各样悠闲本地人,有随手放下电脑包工作的中年大叔、有点了杯冰水悠闲看报的老人、有热烈聊天的年轻女性等等。Cash Only的买单要求能够让你深刻的体会到日式服务的精神,买单的是一位头发全白的老奶奶,精神头非常好,每位进门的顾客都会热情的打招呼,熟识的老顾客还会闲聊上几句。你坐下用餐的时候,她会站在门口发发呆,时不时往店里眺望几下,防止有顾客需要帮忙的地方。

店里的美式咖啡非常不错,喝惯了星巴克之类的深烘的焦苦味,突然喝到带有回甘和花草味道的手磨咖啡会觉得非常新奇,思来想去估计是因为国内的咖啡于我而言是牛马续命的药水,这家咖啡屋的美式才是生活的享受。然后再配上一个抹了薄薄一层果酱的吐司,这个吐司被放进烤箱烘烤过,表层微微泛黄香脆,里面这是吐司面包软软的质地,咖啡的回味再加上吐司酥软、果酱的甜美,确实是难得的口腹之欢。店员会热情看着你吃东西,嘴里一直重复着「どぞ, どぞ......」,看到你享受美味的时候会很开心的默默走开。

我低头吃东西的时候,余光无意间偏见站在门口老奶奶,看我吃得很香的样子,她嘴角上扬比我还开心。老奶奶不会英文,最后我们去付钱的时候她看我要掏卡,最近轻轻念叨着「cash only, cash only」,然后在指示牌子上比划着,神情略带歉意,我恍然赶忙拿出现金递给她,她笑逐颜开接过去,嘴里念叨着什么,指了指账单,然后拿走了1000的纸币剩下的返回给了我。我当时没注意,还是家人提醒,200多的零头老奶奶没收。再后来,我们又去了两次,都是这个老奶奶收的钱,每次都只收我1000块,零头都去掉了,或许是表达cash only歉意,或许是看着小伙子顺眼,或许她就是喜欢顾客喜欢吃他们的东西,或许她就是喜欢看到世界各地的人。

本来想总结思考一下,日本的精致、安静、悠闲带来的感触和对比的。

后来,有点意兴阑珊,去思考这些的意义是什么呢?对两个完全不同的文化、制度的国家评头论足又有什么意思呢?它们仅剩相同的地方大概就是相似的面孔和历史文化渊源了吧!

于我而言,我唯一记住的就是,它是一个难得让我悠闲和松弛的地方。它的漂亮和友善或许可能是他们天生如此,又或许是因为我是一个匆匆游客,又或许是因为我个人的自我感动。

总之,人总会对喜欢的东西才会格外用心

0:00
/0:46