来涩谷苹果店里看了下duo，折痕确实是看不出来，但手滑过去的时候能感觉到，以及这个前摄有点太碍眼了，还有就是这个外屏为什么不能横过来。

最近信息泄露卡被盗刷的新闻没少看，搞得人有点草木皆兵了。 今天买东西用煤炉的 iD 支付，突然让我输密码，连输三次全错。心里一凉，坏了，终于轮到我了啊。 刚刚打开煤炉 App 研究了半天才发现，原来 iD 支付还有个独立密码，而我压根就没设置过。奇怪，其他的店都不需要密码呢。

左边是浏览器里面的cindy，右边是linux客户端，双方的所有会话内容都是共享的，手机上也是同样的效果。只需要跑一个cindy server，就可以在任何能够访问到主机的设备上给cindy下任务，并跨设备管理了。

突然意识到自己已经被职场循化了，例如看到这个人的锁屏壁纸，我的第一反应是，她为什么能够在工作用的电脑上设置能体现私人喜好的明星壁纸。

经常用 AI 写代码的朋友们，可以了解一下领域驱动设计（DDD）这个概念。它的英文全称是 Domain-Driven Design。 平时做开发，很多人习惯先建数据库表、写增删改查，然后把一堆复杂的业务判断散落在控制器和前端组件里。一旦需求变多，字段和逻辑到处缠绕，改一个地方就坏一片。 DDD 的核心思想，就是把重心从底层的数据库和框架，拉回到真实的业务本身。在动手敲代码之前，先理清楚现实业务里的概念、规则和流转关系，让代码直接反映业务本身的逻辑。 在传统软件工程里，落地 DDD 通常围绕三个核心动作展开。 第一个是建立统一语言（Ubiquitous Language）。 在整个项目里，把所有的业务名词定下唯一标准。同一个业务概念，不能在需求里叫客户，在代码里叫用户，在数据库里又叫账号。统一了词汇表，沟通损耗直接抹平。 第二个是划分限界上下文（Bounded Context）。 再大的项目，也不能揉成一团。按照业务职责把系统切分成几个明确的独立边界。比如电商项目里，商品展示、库存流转、支付结算各自是一个独立的上下文，每个上下文只管好自己的规则，跨边界调用只通过清晰的接口契约进行。 第三个是构建充血的领域模型。 不要写那种只有字段、没有业务行为的空壳数据类。把属于某个实体的业务校验、计算逻辑和状态流转，直接封装在实体内部，让核心业务逻辑保持稳定。 搞懂了这套心智，在 Vibe Coding 时代跟 AI 协同就会顺手得多。 大模型写具体代码的速度极快，但它本质上是个概率系统。你给它一段模糊的需求，它顺着概率去猜，必然会胡乱生成一堆缺乏边界的胶水代码。 结合 AI 使用 DDD，最舒服的姿势是做好分工：人类负责搭建领域模型与划定边界，模型负责高效地补全具体实现。 具体的最佳实践可以总结为以下四步： 第一步，建立全局的领域词汇表与契约文件。 在项目根目录的规则文件或者系统提示词里，花几分钟把核心实体名词、状态枚举和核心行为定义清楚。给大模型一套毫无歧义的统一语言，它在命名变量、写类型定义和生成接口时就不会前后打架。 第二步，按照限界上下文限制 AI 的注意力范围。 不要试图让大模型一次性通读并理解几万行的大工程。按照业务边界把代码组织成清晰的模块。每次派发任务时，只把当前上下文里的实体定义、接口契约和相关文件喂给模型。把上下文体积控制在极小范围，模型的幻觉和误改率会大幅下降。 第三步，明确要求模型把规则内聚在实体内部。 给 Agent 提要求时，限制它不要在外层写一堆零散的条件判断补丁，而是把业务规则封装在对应的领域实体里。外层的调用代码越干净，后续让模型修改逻辑或者新增特性时，波及的范围就越小。 第四步，用行为测试作为确定性契约。 在让 AI 敲具体实现之前，先把领域实体的行为测试用例立起来。跑测试通过了才算交付。用严格确定性的单测和编译器，把大模型的概率漂移稳稳按在轨道里。 人类理清概念与划定边界，AI 负责快速落地代码。

维护的DB 比较工具出问题，让我看看咋回事。 换了各种数据反复测试，怎么看结果都正常。 只好把报错那个人的数据要过来。 发现 CSV 格式跟预期的不一样，字段外面的双引号都没了。 就问：这个 CSV 是怎么生成的？ 答：用 Excel 编辑了一下。 ……唉，知道喜欢表格。 但 CSV 是文本文件。直接用 Excel 打开编辑再保存，格式就乱掉了。能不能别啥都往 Excel 里塞。