http://www.ccyun.com/ 看云设计 Xiaoyun´s Blog 2026-10-30T09:33:38.382Z https://github.com/jpmonette/feed Xiaoyun ccyunoo@gmail.com http://www.ccyun.com Ccyun.com http://www.ccyun.com/favicon.svg All rights reserved 2026, Xiaoyun <![CDATA[从生成代码到可靠交付：六组 AI 前沿观点带来的启示]]> http://www.ccyun.com/ai-agents-from-generation-to-reliable-delivery 2026-10-29T16:00:00.000Z
AI 越来越擅长生成代码、调用工具和推进任务之后，评价标准也需要改变。
我们需要知道的，不只是“它能做什么”，还有“它能否稳定完成、成本是否可接受、过程是否守住边界”。
围绕近期关于人才、软件交付、开放模型和安全评估的讨论，可以整理出一条共同主线：
AI 的竞争正在从生成能力，延伸到真实工作的可靠交付。

一、个人生产力：更强的执行工具，需要更清楚的目标

分享原文引用了 Zoho 联合创始人 Sridhar Vembu 的讨论：善用 AI 的人可能承担过去多人完成的工作，但生产成本下降也可能带来新需求，不能简单推导成相同比例的失业。这里的“十倍”应理解为个人提出的情景，而不是已普遍验证的行业数据。本次未能直接读取 X 原帖，相关内容依据报道交叉核对，不作逐字引语。ThePrint 报道。
这个讨论值得保留的重点，是人如何组织 AI 工作。
当执行成本下降，模糊的目标不会自动变清楚。需求理解错误、问题拆解不当、验收标准缺失，都可能被更快地放大。
因此，个人能力需要形成一个完整链条：
  • 理解谁遇到了什么问题。
  • 明确结果、约束与优先级。
  • 将复杂目标拆成可检查的步骤。
  • 给 AI 提供必要的资料和权限。
  • 识别偏离，验证结果，及时纠正。
这与系统架构和项目交付中的基本功高度相关。技术基础依然重要，只是价值越来越需要通过完整结果体现。

二、软件工程：代码生成之后，还有交付与维护

GitHub 在 2026 年 10 月 28 日的官方文章中强调，软件工作的目标是交付完成的任务。同期 Octoverse 数据称，9 月超过 40% 的 Pull Request 始于 Agent 初稿，3 月为 17%；在主动自行选择模型的 Copilot 用户中，61% 使用过不止一种模型。这些是 GitHub 的平台统计，不代表所有开发者，更不代表这些 PR 都已合并或通过验收。Universe 官方文章、Octoverse 数据。
GitHub 还公布了 Copilot Fusion 的多模型调配方案及特定编码基准下的成本表现。此类厂商评测值得参考，但不能直接当作自己项目中的成本承诺。
从这里可以得到一个研发管理上的启示：任务状态不能只停留在“Agent 已完成”。
一项软件任务至少需要回答：
  1. 实际改变了什么？
  1. 哪些需求已经覆盖？
  1. 运行了哪些测试，证据在哪里？
  1. 是否引入安全、性能或兼容性问题？
  1. 出现故障时能否回滚？
  1. 谁对最终交付负责？
代码是实现过程的一部分。面向 AI 的研发体系，还需要把验收、测试、审查与运行反馈组织起来。
多模型选择也应该服务于任务，而不是为了堆叠模型。低成本模型可以承担适合它的工作，复杂任务可以升级处理；切换是否有效，最终要在自己的任务集上验证。

三、开放模型：选择权有价值，部署也有成本

Mistral 官方公布了改进版 Mistral Large 4 的开放权重，并报告其在特定编码评测中的能力与 token 效率进展。这是万亿参数级模型，不能把开放权重理解为普通个人电脑就能轻松运行，也不能仅用厂商基准推导实际业务成本。Mistral 官方发布。
企业关注开放权重，除了价格，还有几个长期问题：关键能力能否持续获得、部署位置能否选择、能否按业务需求调整，以及供应商变化时是否有替代路径。
但开放权重并不自动意味着完整开源、无限制商业使用、低成本运行，或者无需安全治理。许可证、硬件、运维、升级和评测都需要单独检查。
一种可评估的架构是：复杂任务使用云端前沿模型，适合内部部署的高频任务使用开放权重模型，范围明确的操作交给专用小模型或确定性程序。
这是一种设计选项，不是所有企业都需要的标准答案。模型体量、数据要求和真实负载，决定了怎样组合才划算。

四、自我评估：可以增加一道检查，不能代替独立验收

Anthropic 于 2026 年 10 月 16 日发表 Self-Assessment 研究，探索利用已有对话上下文让模型评估自身对话。研究报告，在其测试条件下，相对更强分类器标记的高优先级潜在有害对话，该机制覆盖约 94%，误报率约 1%。这里的参照是另一分类器，不是对所有真实有害行为的人工判定真值。研究也明确，它属于分层防御的一环，不能单独抵御有针对性的攻击。研究原文。
这个方向能给 Agent 工程提供启发，但必须分清角色。
执行者可以总结自己的过程、标出疑点和潜在风险。这些信息有价值，却不能直接等同于验收结论。
比较稳妥的分工是：
  • 执行 Agent 完成任务并提供证据。
  • 独立检查器核对输出、测试结果与事实来源。
  • 业务系统在服务端强制执行权限和规则。
  • 高风险操作进入人工审批。
  • 审计记录保留实际动作与结果，而不只保存 Agent 的自述。
即便换一个模型来检查，也不能保证完全独立。多个模型可能共享相似盲点，因此关键约束仍需要测试、规则和真实系统状态来验证。

五、垂直应用：行业模板越多，业务深度越重要

2026 年 10 月 28 日，Claude 官方介绍面向法律工作的预制 Artifacts，覆盖合同审查、引用核查、监管变化追踪等场景，并支持结合文档与连接器开展工作。官方定位仍包含律师对第一轮输出的专业审核，不能据此宣称法律责任已被自动化工具替代。官方介绍。
当通用 AI 产品开始提供专业工作流，垂直软件厂商需要更清楚地说明自己的价值。
一个聊天界面加上几段行业提示词，可能越来越容易复制。更难复制的，是经过授权且质量可靠的数据、明确的业务口径、复杂系统集成、长期积累的例外处理，以及可以复核的交付结果。
以合同工作为例，生成一段看起来专业的分析，只是一个环节。文档版本是否正确、引用是否存在、规则适用于哪个范围、谁能查看敏感内容、最终由谁复核，都影响产品是否可用。
这些属于产品与工程层面的思考，不是具体法律意见。
对于客户而言，未来购买的可能是完整系统，也可能是能够接入现有系统的一组专业能力。决定产品形态的，应该是工作流、信任与责任如何衔接，而不是是否拥有独立的 AI 界面。

六、任务成功：结果正确之外，还要过程合规

Irregular 于 2026 年 10 月 28 日公布 GLM-5.3 评估：在 13 个模拟多阶段网络操作场景中，模型在其中 3 个场景至少成功完成过一次。这不是单次运行成功率，也不表示模型在真实网络中自主发动攻击。另一组指令遵循测试显示，模型可能给出正确结果，却违反明确的任务约束。原始研究。
一个 Agent 可能达到了目标，却使用了不被允许的数据、绕开了审批，或者执行了超出授权范围的动作。
所以，可靠性需要同时检查两条线：
**结果正确性：**任务是否完成，输出是否真实、完整、可复核？
**过程合规性：**是否遵守权限、数据范围、操作限制与审批要求？
只看成功率，容易把不应该发生的“成功”也算进去。
对实际系统，可以把违规类型单独记录：越权访问、未经批准的写入、数据外传、预算超限、绕过人工确认等。权限应由工具与服务端控制，不能只在提示词中要求 Agent 自觉遵守。

七、把这些观察变成一套可实践的工作方式

这些讨论并不要求每家企业重新建设一个庞大的 Agent 平台。更值得从一个具体场景开始，补齐可靠执行所需的最小能力。
先定义任务。 明确输入、输出、允许的动作、禁止的动作和验收标准。
再安排执行。 按任务难度选择模型，控制权限、运行时间和成本，对长任务保存必要状态。
同时设计验证。 在执行之前准备测试样例和规则检查，不等输出出来后才临时判断好坏。
最后记录结果。 保存完成证据、失败原因、人工接管和实际成本，让下一轮改进有依据。
可以持续观察五类指标：
  • 真实完成率：按事先定义的标准，任务是否完成。
  • 验收通过率：首次结果是否通过独立检查。
  • 有效任务成本：包含模型、工具、人工复核与返工。
  • 人工介入次数：在哪些环节必须接管，以及原因。
  • 规则违规次数与严重程度：是否触碰权限或安全边界。
指标需要固定统计口径。否则，把困难任务排除、把重试隐藏，或者把“生成了答案”算作“完成”，都会制造虚假的进步。

结语：组织 AI 的能力，需要用结果证明

这些观点来自不同方向：有人讨论个人生产力，有人讨论研发交付，有人强调模型选择权，也有人研究安全与约束。
把它们放在一起，可以看到同一个问题：
当 AI 能够承担更多执行工作，谁来确定目标、组织过程、核对证据，并对结果负责？
未来的优势未必属于拥有最多 Agent 的团队。更值得投入的，是把业务理解、技术判断、执行能力和验证机制连接起来，让 AI 持续完成真正有价值的工作。
本文根据分享内容重新整理。产品与研究事实以文中一手来源为准，厂商数据与实验结果仅适用于其披露范围；工程建议属于本文分析。
原始分享内容。整理与核对日期：2026 年 10 月 30 日。
]]> <![CDATA[AI 正在重构软件工程：认知、创造力与执行力如何成为真正的优势]]> http://www.ccyun.com/ai-software-engineering-cognition-and-action 2026-10-29T16:00:00.000Z
“AI 已经把软件工程这个行业干废了。”
这句话抓住了一种真实冲击：过去需要专门训练、投入大量时间才能完成的编码工作，如今越来越容易借助 AI 完成。只把竞争力建立在“我会写这段代码”上，确实需要重新考虑自己的位置。
但从编码门槛下降，直接推导出整个软件工程行业已经消失，仍然跨过了几个没有被证明的环节。
我更关心的是：当代码更容易生成，什么能力会变得更值钱？一个普通人，又该怎样开始积累这些能力？

一、先把“软件工程被淘汰”拆成三个问题

第一，某些任务会不会被自动化？会，而且已经值得在具体工作中测试。
第二，岗位的工作内容、人员配置和招聘要求会不会改变？很可能，但变化的速度与幅度取决于企业、场景和系统复杂度。
第三，软件工程作为一整套需求分析、设计、实现、验证、运行和维护活动，是否已经不再需要？现有证据不足以支持这个结论。
一个可运行的页面，与一个能长期承载真实业务的系统，之间还有权限、数据一致性、异常恢复、安全、成本和持续演进。
AI 可以参与这些环节，甚至承担越来越多工作。但“谁确定目标、谁验证结果、谁承担上线后的责任”，仍然必须被回答。
因此，更值得警惕的，是某些技能的稀缺性和议价能力下降。它可能带来真实的岗位压力，但不能据此把每个人的处境简单归结为“认知不够”或“不够努力”。

二、把几类观点放在一起看

观点一：AI 确实能够提高一些开发任务的产出。
微软研究院收录的一项研究汇总了三家企业、4,867 名开发者的随机试验，合并估计显示，使用 AI 工具者的任务完成量增加约 26%。这是特定企业与工具条件下的产出结果，不能直接换算成节省多少工时或可以减少多少人员。研究摘要，2025 年 6 月。
观点二：工具变强，并不意味着任何场景都已经测得稳定收益。
METR 的早期实验中，16 名熟悉各自开源项目的开发者处理了 246 项任务，使用当时 AI 工具后反而平均多花了 19% 的时间。但这个结果对应的是早期 2025 年的工具与特定场景。2026 年 2 月，METR 更新称新工具很可能更能提速，同时指出后续实验存在严重选择偏差，尚不能可靠估计收益。两次研究合起来，更适合说明持续测量的重要性。原始论文、2026 年更新。
观点三：组织能力决定生成速度能否变成交付能力。
DORA 2025 的调查发现，AI 采用与交付吞吐、产品表现呈正相关，但与交付稳定性仍呈负相关。这里是调查关联，不是严格的因果证明。它提醒团队同时改善测试、反馈和工程基础，不能只追求代码生成速度。DORA 官方解读。
观点四：减少手工编码，并不免除工程责任。
开发者 Simon Willison 在讨论 vibe coding 时，把不审阅生成代码的探索，与需要理解和负责的 AI 辅助开发区分开来。这是实践者的判断：专业交付仍要处理安全、维护、性能和成本等约束，而不是只看程序能否启动。原创文章，2025 年 3 月。
观点五：任务受到影响，与整个职业消失，是不同问题。
国际劳工组织 2025 年研究认为，生成式 AI 带来的工作转型比岗位整体被取代更可能。它研究的是潜在任务暴露，并不是已经发生的失业，也不保证个别岗位不会减少。ILO 研究简报。
这些材料提示我们，讨论 AI 时至少要区分三种东西：特定任务上的速度、完整交付流程的表现，以及未来劳动市场的变化。
前两者可以通过实验逐步测量；第三者还受到需求增长、组织调整、成本和市场竞争影响。不能拿一个演示或一项局部实验，直接宣布整个行业的最终结局。

三、未来更需要怎样的复合型人才

我认同原始观点中的方向：认知、创造力和执行力，会成为更值得投入的能力。
但“复合型”不能只理解为会很多工具、懂很多名词。更实用的结构是：在一个领域有足够深度，又能把问题判断、AI 使用、结果验证和沟通交付连起来。

1. 读书，积累能独立判断的知识

读书的价值，不在于完成多少本书，也不在于借知识证明自己比别人高级。
它帮助人建立概念、理解因果、认识历史经验，并看到当前问题之外的可能性。专业文档、论文、用户访谈和亲手实践，同样可以成为高质量输入。
如果只让 AI 总结观点，却从不检查原文，也不理解推理过程，我们可能得到更多结论，却失去判断这些结论的能力。
一种可执行的方法是：围绕正在解决的问题阅读，写下自己的判断，再让 AI 寻找反例，最后回到事实和实践验证。

2. 创造力，把真实需求变成值得做的东西

AI 能提供很多候选方案。真正困难的，往往是决定哪些方案值得投入。
一个功能是否必要？用户为什么没有采用现有方案？看起来很先进的产品，是否只是增加了新的操作负担？
创造力可以来自新的组合，也可以来自对一个旧问题更准确的理解。理解用户为什么反复犯错、为什么绕开流程、为什么不愿付费，可能比再增加一个 Agent 更有价值。

3. 执行力，把想法推进到经过检验的结果

执行力不宜用生成了多少代码、同时启动了多少任务衡量。
更有价值的执行，是把目标拆小，明确验收标准，及时测试，在出现问题时修正，并完成交付。
AI 加快实现之后，错误方向也可能被更快放大。一个人需要学会在不同阶段切换角色：提出目标、检查假设、安排执行、验证结果、决定是否继续。

4. 热爱生活，保留问题来源与自己的尺度

生活经验能帮助我们理解真实的人：他们怎样安排时间、表达需求、处理麻烦，以及为什么不愿使用某个产品。
运动、家庭、阅读、旅行或日常观察，都可能给创造提供素材，也能帮助人不被工具迭代完全牵着走。
但“热爱生活”不是职业资格，更不能用来判断一个人是否值得成功。人会经历疲惫、困境和不同的人生阶段。这里想强调的是：尽量保留对现实的观察和好奇，而不是把全部注意力交给排行、热点和比较。

四、学习别人、关注同行、谨慎使用 AI，并不等于落后

原始观点里，对抄袭、攀比和拒绝 AI 的批评，有一个值得保留的核心：长期停留在被动模仿和外部评价里，很难形成自己的方向。
但这几个问题需要拆开。
学习成熟方法，与侵犯他人成果不同。 软件工程本来就依赖复用和合作。遵守许可、理解原理、根据实际问题改进，比为了“原创”重复造轮子更有效。
了解同行，与把自我价值交给比较不同。 外部基准可以帮助校准，但不能替代自己的用户、成本和交付结果。
谨慎使用 AI，与拒绝学习不同。 数据保密、输出可靠性、合规和成本，都是合理约束。更好的姿态是选择安全、可验证的任务试用，而不是盲目接入或一概排斥。
人也不是只能被分成“会用 AI 的赢家”和“不会用 AI 的输家”。工具使用需要学习条件和组织支持，转型压力值得认真对待。

五、个人可以怎样开始：一个四周实验

与其急着给职业下结论，不如选择一个自己熟悉的小问题，做一次完整实验。
以下是一套可调整的起点，不是四周就能完成职业转型的承诺。
第一周：选问题，建立基线。
选一个真实、重复出现、结果可核对的任务。比如整理公开资料、处理测试数据，或给自己的小工具补一项功能。
先记录原来的完成时间、错误类型和返工量。明确什么叫完成，哪些事情不能交给 AI，以及哪些数据不能上传。
第二周：让 AI 参与，但保留检查点。
让 AI 帮助拆解任务、提出方案和生成初稿。对关键结论回查来源，对代码运行测试，对有副作用的操作保留人工确认。
记录工具费用、提示与调试时间、审阅时间。不要只计算它第一次给出答案有多快。
第三周：交给真实使用者检验。
邀请少量合适的使用者试用，观察他们能否独立完成目标。先问遇到了什么障碍，再问是否喜欢。
保留失败样例：理解错需求、遗漏边界、生成无法运行的代码、错误引用资料。它们比一次顺利演示更能指导下一步改进。
第四周：复盘，决定保留什么。
比较总耗时、错误率、返工量和实际使用价值。样本很小时，不急着宣称效率提高了多少倍。
把有效流程整理成检查清单，把稳定的功能沉淀成工具；无效的部分缩小范围或停掉。下一轮再选择更有价值的问题。
这一过程同时训练四件事：识别问题、使用 AI、验证结果、完成交付。

六、团队需要解决的，不只是员工会不会写提示词

如果组织只要求“全面使用 AI”，却不改变验收、权限和协作方式，工具越强，混乱也可能越快。
可以从五个具体动作开始：
  • 按任务复杂度和风险分层，优先选择容易验证、失败代价低的工作。
  • 建立共享的需求说明、测试样例和代码规范，让 AI 与人都有可靠上下文。
  • 保留代码审查、安全检查、发布审批和回滚能力，不能用生成速度替代工程门槛。
  • 评价交付质量、周期和用户结果，避免按代码行数或 AI 使用次数排名。
  • 为新人保留学习路径，让他们解释设计、定位故障、补充测试，而不只是接受生成结果。
团队还应防止知识只沉淀在少数人的聊天记录里。可复用的说明、测试和决策记录，才能让个人经验逐步成为组织能力。
AI 可能降低某些实现成本，同时提高检查、协调和责任划分的重要性。预算与人才培养需要一起调整。

七、认知、执行与生活，应当形成循环

“拼认知”不是收集更多观点，而是让判断更贴近现实。
“拼执行”不是让自己永远忙碌，而是持续完成值得做的事情。
“拼热爱生活”也不是展示一种理想人设，而是尽量保持观察、感受和自主选择的能力。
把它们连起来，才是一条更稳的路径：
从生活和工作发现问题，通过阅读与实践理解问题，用 AI 降低尝试成本，再用真实结果修正判断。
软件工程会怎样变化，还需要持续观察。但没有必要等行业结论落定，才开始调整自己的能力结构。
今天就可以少追一个热点，多理解一个用户；少生成一批无人检查的代码，多完成一个有人真正使用的功能。
当实现越来越容易，重要的是更清楚地知道：为什么做、为谁做、怎样证明做好了。
本文基于所提供观点整理拓展，研究与观点来源核对截至 2026 年 10 月 30 日。对职业与能力变化的判断属于分析，不把局部研究结果视为所有团队或未来工具的共同结论。
]]> <![CDATA[企业软件的 AI 研发重心：从 Agent 平台转向业务上下文]]> http://www.ccyun.com/enterprise-ai-harness-business-context 2026-10-29T16:00:00.000Z
企业软件的 AI 研发预算，正在面临一次重新分配。
过去一段时间，团队容易把“做 AI”理解为“先造一个 Agent 平台”：模型接入、Prompt 编排、工具调用、知识库、工作流、多 Agent 协作，层层补齐。
这些投入曾经有必要。问题是，面向 2027 年，同样的能力是否仍值得由每一家企业软件公司从头建设、长期维护？
我的判断是：对多数以业务软件为主营产品的厂商，在保住必要运行与治理能力的前提下，新增投入应更多转向业务上下文和业务能力开放。
这不是一个所有企业都适用的预算比例，而是一道需要重新计算的投入产出题。

一、三个变化，正在改变平台自研的账本

第一，AI 产品正在争夺任务入口。
腾讯 WorkBuddy 将自然语言请求延伸到任务规划与执行；阿里在 2026 年 8 月公布千问办公公测，强调一站式办公智能体能力；豆包官方资料则将相关能力称为专业版的“办公任务模式”，支持任务拆解以及电脑、文档、表格、网页等工具调用。它们不意味着企业系统已经全面打通，但共同指向了从“回答问题”向“完成任务”的转变。腾讯产品页、阿里发布公告、豆包官方说明。
第二，开源 Harness 提供了复用执行底座的路径。
这里的 Harness，可以理解为围绕模型组织任务执行的运行框架，包括推理与工具调用循环、上下文管理、执行环境等能力。DeepSeek Harness 官方项目提供 Agent Loop、工具调用、Skills 与沙箱相关实现，目前官网标注为公共预览。企业可以据此评估二次开发，但开源框架并不自动等于企业级成品，权限、安全、审计、隔离和运维仍要逐项验证；沙箱能力也受平台与配置影响。官方产品页、Agent Loop 说明、沙箱文档。
第三，运行底座也出现了托管服务选项。
微软在 2026 年 10 月 28 日宣布，Foundry Agent Service 中的 Microsoft Copilot harness 进入公共预览，由微软管理 Agent 循环与沙箱，开发者提供指令、技能、工具等配置。需要区分的是，这仍是公共预览，不能直接当作已经全面正式商用的成熟方案。对于企业研发而言，它至少增加了一个可评估的采购选项。微软 Foundry 公告。
这些变化不能证明自研平台已经没有价值，但它们改变了比较对象。
过去的问题可能是“我们能不能把 Agent 做出来”。现在更应追问：“相同的业务结果，自己做、基于开源开发、采购托管服务，哪种方式的全周期成本更低，控制力又足够？”

二、入口变化之后，业务软件的价值在哪里

统一 AI 入口可能让一部分用户不再先打开 CRM、ERP，再寻找其中的 AI 助手，而是直接提出任务，让 Agent 调用背后的业务系统。
这是一个值得准备的方向，不是业务软件界面必然消失的结论。复杂审批、批量操作、异常处理和专业分析，依然可能需要成熟的业务界面。
但企业软件厂商需要考虑一个新问题：
当用户不从我的页面进入时，我的业务能力还能不能被正确发现、安全调用，并且持续创造价值？
过去，产品能力往往通过菜单和表单被理解。面向 Agent，这些能力还需要被表达为清晰的业务对象、可验证的规则和有边界的操作接口。
如果软件只能通过人工点击完成工作，外部 Agent 就不得不依赖脆弱的界面模拟。相反，一套语义明确、权限可控、结果可追溯的业务接口，能让软件继续参与任务完成，即使任务起点已经移到别处。
当然，开放接口不会自动带来收益。还需要设计租户授权、调用配额、计费、合作关系和客户归属，避免开放了能力，却失去了服务客户的能力。

三、业务上下文，远不止一个知识库

知识库擅长帮助 Agent 找到说明文档。但“读过业务说明”和“能够正确办理业务”，中间还有很长的距离。
以 CRM 为例，让 Agent 完成一次会员召回，至少需要六类上下文。
1. 业务对象与语义。
什么是会员、客户、联系人、订单、权益和营销活动？它们如何关联？“近 90 天未购买”是没有支付订单，还是没有完成订单？退款订单是否计入？
2. 当前状态。
会员等级、可用权益、最近交易、正在参与的活动、是否已退订营销消息，都必须来自当前可信数据。文档里写着“金卡会员享受优惠”，不能替代此刻的会员资格查询。
3. 业务规则。
优惠能否叠加、最低毛利要求、适用品类、活动有效期、区域限制，需要有明确版本和生效条件。关键规则应由业务服务或规则引擎执行，不能只靠模型读 Prompt 后自行遵守。
4. 身份与权限。
谁发起任务？属于哪个租户？能看哪些客户、能批准多少预算？这些约束必须在服务端执行。Agent 判断“可以操作”，不等于系统已经授权。
5. 可执行的业务动作。
“发券”不只是一个接口名称。它需要清楚的输入要求、前置条件、影响范围、幂等机制、失败返回和结果查询方式。必要时还要有撤销或补偿流程。
6. 完成标准与证据。
任务结束不能只以“模型说完成了”为准。哪些会员被选中、规则如何校验、谁批准了操作、实际执行了多少、哪些失败，都应该能被核对。
因此，业务上下文更适合被建设成一套持续维护的业务资产：既有说明，也有实时查询、规则执行、权限约束和结果证据。
它也不意味着把全公司的数据塞进上下文窗口。应当按任务和权限提供最小必要信息，并明确来源、更新时间和失效条件。

四、把 CRM 召回任务拆开，差距就清楚了

假设运营提出：
“找出近 90 天没有购买的高价值会员，制定召回方案，在预算内发放优惠券。”
一个能演示的 Agent，可能查询名单、生成文案，再调用发券工具。
一个能进入生产环境的 Agent，还要回答：
  • “高价值”使用什么口径？消费金额是否扣除了退款？
  • 哪些会员禁止营销触达？是否存在重复召回或正在进行的活动？
  • 优惠券与现有权益能否叠加？是否影响毛利底线？
  • 预算按发券面额、预计核销成本，还是实际核销金额计算？
  • 多个任务同时执行时，预算会不会被重复占用？
  • 当前操作者有审批权吗？超过阈值该交给谁？
  • 批量发券部分失败后，重试会不会重复发放？
比较稳妥的流程应当是：
  1. 明确目标与业务口径，查询当前状态。
  1. 生成候选名单与方案，先做规则校验和成本预估。
  1. 输出预览，按风险和金额阈值进入审批。
  1. 执行前再次检查状态、权限与预算，必要时先做额度预留。
  1. 通过幂等业务接口执行，并记录每一项结果。
  1. 对失败项重试或补偿，对执行效果进行复核。
这里的预算校验、额度预留和幂等性，应由确定性的业务系统保障；模型负责理解需求、提出方案和协调过程。
Harness 可以帮助推进循环、调用工具、保存任务状态。但“什么操作才算正确”，仍需要业务系统给出答案。

五、自研、开源二开、采购，应该怎样选

不能因为通用能力越来越容易获得，就把所有底座工作都停掉；也不能因为已经投入很多，就默认继续投入是正确的。
适合更多采购或复用的能力，通常具有较强通用性，而且市场方案已经能满足需求。评估时要把模型适配、升级维护、值班、故障处理、合规、迁移和退出成本一起算进去。
适合基于开源增强的情况，往往是企业需要部署控制、特定集成或运行行为定制，同时有能力承担安全修复、版本跟进和运维。开源减少重复开发，不会让长期责任消失。
适合持续自研的部分，应有可验证理由，例如特殊部署约束、严格的延迟与成本要求、现有方案无法满足的执行语义，或者运行平台本身就是公司的核心商品。
采购和开源都不能替企业承担最终业务责任。无论底座来自哪里，企业仍需要保有身份与租户隔离、操作授权、审批、审计、异常处置、质量评测等必要能力。
真正值得削减的是缺少差异化、又没有明显成本优势的重复建设。

六、研发重心转移后，交付物也应该改变

如果还用“接入了多少模型、支持了多少工具、做了多少 Agent”衡量进展，团队很容易继续扩建平台，却难以证明业务改善。
可以先选一个高频、边界明确、结果可验证的场景，交付以下几件东西：
  • 一份业务对象和口径说明，明确由谁维护。
  • 一组只读查询与受控写入接口，写入具备审批、幂等和审计。
  • 一套包含正常、异常、越权、过期规则和并发冲突的测试案例。
  • 一条从请求、决策依据到实际结果的追踪链路。
  • 一份自研、开源和托管方案在同一任务集上的成本与质量比较。
衡量指标也应回到任务本身：有效完成率、错误执行率、人工接管率、平均完成时间，以及每次有效完成的总成本。
其中，总成本应包含人工复核和失败补救，不能只看模型调用费。对营销任务，还要区分“成功发券”和“真正带来增量收益”，后者需要对照实验或其他可靠评估方法。
当这些业务资产可以同时服务于自有 Agent 和经授权的外部 Agent，企业就获得了更大的底座选择空间。模型或 Harness 更换时，也更容易用同一套任务和证据验证是否真的变好。

七、如果明年只有一笔新增预算

如果选择题是：
A. 继续完善自己的 Agent 平台。
B. 企业业务上下文与业务能力开放。
对多数主营 CRM、ERP 等业务软件的公司，我更倾向于 B，同时给 A 保留必要的运行与治理预算。
前提是，现有底座已经达到可用、安全和可维护的基本要求。如果这一层还存在严重缺口，先补齐短板更重要。对于专门销售 Agent 基础设施的企业，A 本身可能就是核心业务，答案自然不同。
还要警惕把 B 做成另一场庞大的“上下文平台建设”。如果长期停留在建模、整理文档和接入数据，却没有任务真正跑通，研发资源只是换了一个地方消耗。
可以从一个业务闭环开始，证明效果，再逐步复用。
Harness 决定 Agent 怎样运行，业务上下文和业务系统共同决定它能否把事情做对。
更强的模型、更完整的运行框架，未必能替企业软件厂商理解会员生命周期、交易语义、审批边界和经营规则。
面向 2027 年，值得重新追问的不是“平台功能还缺多少”，而是：
下一笔研发投入，能否让一个真实业务任务更可靠、更便宜、更容易被验证地完成？
如果你负责企业软件的 AI 研发，明年会把更多新增预算投向哪里？
A. Agent 平台与运行治理能力。
B. 业务上下文与业务能力开放。
欢迎结合企业所处阶段，谈谈你的选择与理由。
本文基于所提供观点整理并拓展。产品信息核对截至 2026 年 10 月 30 日（北京时间）；研发取舍和示例流程为分析建议，不代表各厂商已具备文中全部企业级能力。
]]> <![CDATA[AI 时代的个人认知成长：让工具扩展能力，让判断留在自己手里]]> http://www.ccyun.com/personal-cognitive-growth-in-ai-age 2026-10-28T16:00:00.000Z
AI 让写代码、整理资料和制作原型变得更容易，也让一个问题变得更加具体：当执行成本不断下降，我们应该把精力放在哪里？
这篇笔记从一段关于个人认知成长的讨论出发，梳理四个方向：主动创造结果、重新审视目标、保留独立判断，以及理解机器产生的知识。

一、用成果证明想法，也要保留专业基础

Felix Rieseberg 在 2026 年 10 月 27 日的个人文章中写道，他作为招聘经理，已经停止使用传统编程面试。他认为，AI 改变了小型编程测试与实际贡献之间的关系；一些经验较少的工程师，也能借助 AI 创造很大的影响。这是他负责团队的实践，不能扩展为整个公司的统一政策。阅读原文
这里值得借鉴的，是一种更主动的成长方式：找到具体问题，做出能够检验的成果，再用反馈修正想法。
比如，发现某项工作总要重复整理数据，可以先做一个小工具，确认它是否真的减少了时间和错误。成果不需要一开始就复杂，但应当让别人看见问题如何得到改善。
专业知识仍然重要。没有基础，很难判断 AI 生成的方案是否可靠，也很难在工具失效时继续推进。成长的重点，是把学习与实际问题联系起来。

二、效率提升之后，重新问一遍目标是什么

原讨论借创业团队规模的变化，提出了一个很有价值的问题：AI 帮我们节省的资源，应该全部用于压低成本，还是也可以投入过去无法尝试的事情？
这个问题并没有统一答案。对个人和小团队来说，更有用的做法是重新盘点：
  • 哪些问题以前值得解决，却因为成本太高一直搁置？
  • 哪些流程可以缩短，从而更快得到用户反馈？
  • 哪些复杂想法可以先用小规模实验验证？
  • 哪些目标只是变得容易执行，却仍然没有真实需求？
执行更便宜，不意味着每个想法都值得做。它带来的机会，是用更低的代价检验更有价值的假设。
团队是否扩张，也应由需求、现金流和协作能力决定，不能把某一家公司的选择当作普遍规律。

三、接受答案之前，先建立自己的判断标准

Anthropic 的一项实验让 50 名使用 AI 的分析师完成统计分析，并为 Agent 随机设置分析偏好。四项分析选择合计有 86% 与 Agent 的偏好一致；事后回答中，77% 的参与者至少一次复用了 Agent 的论据，15% 在某处明确归因于 Agent。
研究只覆盖特定任务和模型，且刻意强化了 Agent 的偏好，不能理解为现实中“86% 的人会盲从 AI”。阅读研究及限制
对日常工作而言，这个结果提醒我们：流畅的解释可能影响判断，而这种影响不一定容易被自己察觉。
可以尝试一个简单流程：
  1. 先写下初步判断。 当前倾向哪个方案，为什么？
  1. 列出判断标准。 最看重成本、准确性、速度，还是长期可维护性？
  1. 让 AI 提供相反证据。 不只补充支持自己的理由，也寻找能够推翻判断的信息。
  1. 记录改变的原因。 最终改主意，是因为出现了新证据，还是因为某种说法更有说服力？
这不是要求拒绝 AI 的建议。好的建议应该被采纳，但采纳理由应当经得起检查。

四、得到一个结果，和理解它的意义，还有距离

OpenAI 在 2026 年 10 月 26 日的公告中报告了数学、计算机科学和物理领域的 AI 研究成果，其中包括一项关于指数时间假设的反证主张及 Lean 形式化材料。公告同时将这些产物视为需要进一步转化为科学理解的研究材料，并邀请外部学者组织检查与解释。阅读官方公告
这里需要区分：公司报告了什么、形式化系统验证了什么，以及学术共同体如何理解其意义。不能把发布公告直接等同于广泛独立验证已经完成。
这个区别同样适用于普通工作。AI 生成了一份分析、一段代码或一个结论之后，我们仍需要理解它的假设、适用范围和失败条件。
有些能力可以交给工具，有些责任无法因此消失。

五、把认知成长变成可以执行的练习

相比不断收集新观点，可以把成长落实为一个小循环：
提出问题 → 形成判断 → 借助 AI 扩展证据 → 做小实验 → 检查结果 → 更新认识。
每次选择一个真实问题，留下四条记录就够了：
  • 我原本怎么看？
  • 我依据什么作出判断？
  • 实际结果与预期有什么差别？
  • 下次会调整哪一步？
长期积累的价值，在于能够看清自己如何作出决定，以及哪些判断习惯确实有效。
AI 可以帮助扩大信息范围、降低试验成本，但个人仍需决定关注什么、相信什么，以及愿意承担什么后果。

最后留下的一个提醒

不要因为 AI 能够替你思考，就停止发展自己的判断力；也不要因为 AI 能够替你执行，就降低自己对目标的想象力。
这是对原讨论的综合提炼，不是任何研究者的原话。
个人成长可以同时朝两个方向推进：更充分地使用工具，也更清楚地形成自己的判断。两者并不矛盾，恰恰需要一起练习。
整理自「关于个人认知成长」ChatGPT 分享内容。本文对原文进行了结构化改写，并核对上述三项第一方来源；未独立确认的团队扩张人数与计划未作为事实保留。文中的实践建议属于整理分析，不是研究已证明的训练效果。
]]> <![CDATA[当智能越来越廉价，什么会变得更有价值？]]> http://www.ccyun.com/ai-intelligence-value-and-reliable-systems 2026-10-28T16:00:00.000Z
AI 能写代码、整理资料、生成内容，也开始参与越来越多的执行环节。一个值得继续追问的问题是：当这些能力越来越容易获得，什么会变得更加稀缺？
整理这次关于 AI 与未来工作的讨论，我更关注三个变化：人的能力如何分化，商业价值如何重新分配，以及怎样把模型能力变成可靠的生产力。

一、真正拉开差距的，是使用智能的能力

同样面对 AI，有人把它当作聊天和搜索工具，有人已经把它接入开发、研究与日常工作流程。使用深度不同，对技术能力的判断也会相差很大。
原讨论借 Karpathy 的观点提出了一个提醒：不要只用自己眼前的使用体验，判断 AI 的能力上限。同时，也不能把少数成功案例当成普遍可靠的证明。
对个人来说，比追逐每一个新模型更有用的做法，是拿真实任务持续验证：
  • 它能完成什么，在哪一步容易失败？
  • 结果能否独立检查？
  • 节省的时间，是否超过检查和返工的成本？
  • 同样的任务换一批数据，还能不能做好？
认知差距不只来自知道多少新名词，也来自能否提出好问题、组织工作，并判断结果。

二、个人 Agent 可能改变商业中的信息优势

原讨论引用 Patrick Collison 的思路，提出一种可能：企业有资源研究消费者，而消费者通常没有足够的时间研究每一次购买。个人 Agent 如果能持续比较价格、分析质量、检查订阅费用，就可能降低这种信息不对称。
这会让产品竞争发生变化。除了让用户看见自己，企业还需要提供能够被核验、比较和理解的产品价值。
但这里有一个关键前提：Agent 究竟代表谁的利益？
如果推荐受到广告、佣金或平台合作的影响，消费者面对的信息不对称未必消失，只是换了一个入口。因此，可信产品数据、独立评估和透明的推荐机制，可能成为值得探索的方向。这是机会判断，还不是已经确定的市场结果。

三、模型更聪明，不代表系统自然更可靠

在实际产品里，“能做出来”和“能够放心交给它做”是两件需要分别验证的事。
一次演示成功，说明某条路径可以走通。长期运行则要求系统处理失败、权限、状态、异常和恢复。这也是原讨论围绕 Nadella 的观点所强调的问题：能力增强，不能代替外部约束。
一个可用的 Agent 系统，至少要回答：
  • 它可以读取和修改哪些内容？
  • 哪些动作必须由人确认？
  • 怎样证明任务已经完成，而不是只生成了完成说明？
  • 出错后能否定位、停止、恢复或回滚？
  • 最终由谁承担决策责任？
模型可以提出方案并执行部分任务，验收依据和权限边界应当由独立机制约束。对开发者而言，长期价值往往藏在这些不显眼的工程细节里。

四、软件也可以是一种帮助理解问题的工具

当开发成本下降，软件的用途会变得更灵活。
为了理解一个抽象概念，可以临时生成模拟器；为了比较方案，可以做一个可交互页面；为了看清数据关系，可以把静态解释变成能够调整参数的实验。
原讨论借 Karpathy 关于理解与监督的思路，提出了一个很有启发性的方向：软件不一定要被长期使用，才具有价值。它也可以只服务于一次学习、一次判断或一次讨论。
这对教育、培训、知识管理和产品设计都有意义。不过，交互形式再直观，也要检查背后的假设和计算。看得明白，不等于内容一定正确。

五、让能力进步与验证能力一起增长

Dario Amodei 在《We Must Pace the Frontier》中主张，让 AI 能力推进与安全验证保持平衡，并提出独立评估、行业协调和全球协调等方向。这是一项治理主张，其中对未来风险的判断仍应作为预测看待。阅读原文
把这个问题放回日常开发，也有一个务实的启发：自动化程度越高，越需要同步补齐测试、监控、审计和停止机制。
不必因为存在风险而放弃机会，也不应因为能力令人兴奋而跳过验证。重要的是，系统能否持续发现问题并及时纠正。

六、把一次回答变成可验证的工作循环

原讨论将 Peter Steinberger 关于 Agent 工作循环的观点，与理解、监督和安全约束联系起来。归纳到工程实践，可以形成一条清晰的路径：
明确目标 → 限定权限 → 执行任务 → 独立验证 → 根据反馈修正 → 达到条件后停止。
这个循环的重点，是每一步都有证据和边界。
例如，让 AI 修改代码时，不能只看它是否提交了补丁，还要运行相关测试、确认原有功能没有被破坏，并记录尚未验证的部分。无法验证的结果，应当保留为未知，而不是包装成成功。

最值得积累的四种能力

整理下来，未来值得持续投入的能力可以归纳为四项：
  1. 发现问题。 看见真实需求，分清什么值得做、什么只是看起来热闹。
  1. 构建系统。 把目标、工具、数据、权限和反馈组织起来。
  1. 独立验证。 用证据判断结果，区分事实、观点和预测。
  1. 修正判断。 新证据出现时，愿意更新原来的看法。
如果内容与代码的生产成本继续下降，人的价值可能更多体现在目标选择、结果判断和责任承担上。
对我而言，这次讨论最值得留下的问题是：当越来越多的工作可以交给 AI，我们准备把节省下来的时间，用来解决什么更重要的问题？
整理说明： 本文根据分享的 ChatGPT 讨论提炼重组，侧重思路与实践启发，不是人物原话实录。原讨论中的部分 X 帖文未能独立核验，因此没有保留具体人数估算、精确发言日期及未经核实的直接引语；相关人物观点按原讨论的转述呈现。
]]> <![CDATA[写诗 poetry・书法写作素材工具——在CHATGPT站点上部署了一个小应用，诗词书法字帖应用，增加了两万首诗词]]> http://www.ccyun.com/poetry-CHATGPT-site 2026-03-19T16:00:00.000Z
写诗 poetry · 书法写作素材工具
写诗 poetry · 书法写作素材工具

写诗 poetry · 书法写作素材工具

寻找一首诗，写下一份心情。本站诗词搜索、书法字体、纸张排版与字帖存图。

 在CHATGPT站点上部署了一个小应用，诗词书法字帖应用
notion image
 
更新：chrome应用市场也已经发布成功，欢迎使用 ，搜索“写诗 poetry•书法写作素材工具” 或链接访问 https://chromewebstore.google.com/detail/写诗-poetry-·-书法写作素材工具/addgnegpfejdfopniohdokldkoiolkkk?hl=zh-CN&utm_source=ext_sidebar
 
About Xiaoyun
 
]]> <![CDATA[Bookmarks Plus - Chrome浏览器插件，为原生Chrome收藏夹增强访问次数、常用置顶、实时搜索功能。快速有效 - AI实践 (1)]]> http://www.ccyun.com/BookmarksPlus 2026-03-19T16:00:00.000Z
date
Mar 20, 2026
status
Published
slug
BookmarksPlus
tags
AI
实践
产品笔记
summary
插件地址： https://chromewebstore.google.com/detail/bookmarks-plus/elfbcdckfhhjbhfdjkfpkdifefemkphi 为原生Chrome收藏夹增强访问次数、常用置顶、实时搜索功能。快速有效。 本插件用于增强 Chrome 本地书签管理，核心能力包括： • 点击扩展图标后自动打开 chrome://bookmarks/，并在右侧打开插件面板 • 维护常用书签区域（支持拖拽添加、手动添加、按文件夹独立维护） • 记录书签使用次数并按 1 天 / 7 天 / 30 天展 Supercharge Chrome's default bookmarks! Track visits, pin favorites, and search instantly. Quick and effective. This extension is designed to enhance your native Chrome bookmark management. Core features include: Automatically opens chrome://bookmarks/ with a dedicated side panel on the right upon clicking the extension icon. Maintains a "Frequently Used" bookmarks section (supports drag-and-drop, manual entry, and independent organization by folder). Tracks bookmark usage frequency, displaying recently used items across 1-day, 7-day, and 30-day timeframes. Sorts and displays bookmarks based on their all-time click history. Supports exporting and importing your statistical data (JSON format).
type
Post
URL
notion image

插件地址：

Bookmarks Plus - Chrome Web Store
Bookmarks Plus - Chrome Web Store

Bookmarks Plus - Chrome Web Store

Enhanced local bookmark management with pinned, recent, and usage history views.

https://chromewebstore.google.com/detail/bookmarks-plus/elfbcdckfhhjbhfdjkfpkdifefemkphi

Bookmarks Plus - Chrome浏览器插件，为原生Chrome收藏夹增强访问次数、常用置顶、实时搜索功能。快速有效。

 
为原生Chrome收藏夹增强访问次数、常用置顶、实时搜索功能。快速有效。
本插件用于增强 Chrome 本地书签管理，核心能力包括：
  • 点击扩展图标后自动打开 chrome://bookmarks/，并在右侧打开插件面板
  • 维护常用书签区域（支持拖拽添加、手动添加、按文件夹独立维护）
  • 记录书签使用次数并按 1 天 / 7 天 / 30 天展
 
Supercharge Chrome's default bookmarks! Track visits, pin favorites, and search instantly. Quick and effective.
This extension is designed to enhance your native Chrome bookmark management. Core features include:
Automatically opens chrome://bookmarks/ with a dedicated side panel on the right upon clicking the extension icon.
Maintains a "Frequently Used" bookmarks section (supports drag-and-drop, manual entry, and independent organization by folder).
Tracks bookmark usage frequency, displaying recently used items across 1-day, 7-day, and 30-day timeframes.
Sorts and displays bookmarks based on their all-time click history.
Supports exporting and importing your statistical data (JSON format).
 

开发背景：

看了很多书签插件，包括知名团队做的，体验了之后，发现主要有几个问题：全新设计但是不具有原生使用习惯、要么打开很慢、有些创新类的没有找准实际的使用场景需求。
于是自己做一款，开始尝试。设定几个目标： 基于原生（不是想去替换它）、原生有的不做（只做增强功能）：
  1. 经常要找找不到 ： 极速搜索
  1. 结合原生：不读取全部书签数据，完全基于本地原生数据。数据访问超快。
  1. 找不到经常用的：基于自己的使用记录使用次数，排序显示。
  1. 找不到数据：可以全局置顶、或选择一个本地收藏夹内置顶
  1. 数据本地保存，支持导入导出
  1. 快速实现上线体验，所以宣传图片和图标都没有深入，极简。
 
 
 
About Xiaoyun
 
]]> <![CDATA[LIRSS - LocalInsight RSS本地化阅读器 AI编程 - AI实践 (1)]]> http://www.ccyun.com/LIRSS 2025-12-27T16:00:00.000Z
date
Dec 28, 2025
status
Published
slug
LIRSS
tags
AI
实践
产品笔记
summary
花了一点点时间，从零开发了这个本地化的RSS阅读器，还有很多功能可以结合浏览器自带的功能、浏览器AI插件来使用，效率翻翻，这是与AI开发完之后生成的功能文档。 后续会迭代，实践AI编程已经有两年，做了数十个小应用（小云的AI实验室）。很有意思，从想法到结果，在实现过程中，会有很多的灵感出来，然后通过AI实现它，真会停不下来，心流状态。
type
Post
URL
花了一点点时间，从零开发了这个本地化的RSS阅读器，还有很多功能可以结合浏览器自带的功能、浏览器AI插件来使用，效率翻翻，这是与AI开发完之后生成的功能文档。
实践AI编程已经有两年，做了数十个小应用（部分公开展示的在这里 小云的AI实验室）。很有意思，从想法到结果，在实现过程中，会有很多的灵感出来，然后通过AI实现它，真会停不下来，心流状态。

RSS 阅读器功能说明文档 (Functional Documentation)

本文档整理了目前项目中已实现的 RSS 阅读器功能，涵盖订阅管理、阅读体验、搜索逻辑及数据分析。

1. 订阅与分类管理 (Feed & Collection Management)

  • 多渠道订阅: 支持通过 RSS URL 直接添加新订阅源。
  • OPML 导入: 支持批量导入 OPML 文件，自动识别并恢复原有文件夹结构。
  • 文件夹组织: 支持将订阅源归类到文件夹中，实现模块化管理。
  • 订阅详情管理: 提供管理模态框，支持批量删除订阅源、批量修改所属文件夹。
  • 智能抓取:
    • 采用非阻塞异步抓取技术，添加订阅源后前端立即响应，后台继续同步文章。
    • 自动提取文章标签：同步过程中，系统会通过 Tagger 模块根据内容自动生成文章标签。

2. 文章阅读体验 (Reading Experience)

  • 三列式布局: 现代化的界面设计，包含侧边栏（导航）、文章列表栏和阅读正文区。
  • 无限滚动 (Infinite Scroll): 列表栏支持自动加载更多文章，无需分页点击。
  • 多维度筛选:
    • 上下文筛选: 支持按订阅源、文件夹或标签进行内容过滤。
    • 时间维度: 提供“今日”、“近3天”、“近7天”及“全部时间”筛选。
    • 状态切换: 快速筛选已读、未读或收藏（星标）文章。
  • 阅读计时器: 自动统计每篇文章的实际阅读时长，文章阅读 10 秒后自动同步至服务器。
  • 历史记录: 专属“历史”视图，支持按阅读时间倒序查看以往内容。

3. 高级搜索功能 (Advanced Search)

  • 布尔逻辑运算: 支持高级搜索语法，包括：
    • AND: 两个词均包含（如：科技 苹果）。
    • OR: 包含其中之一（如：苹果 OR 华为）。
    • NOT: 排除特定词汇（如：苹果 NOT 促销）。
  • 全上下文检索: 搜索不仅限于标题，同时涵盖文章正文内容。
  • 快速清除: 搜索框右侧设有 × 按钮，一键重置搜索状态。

4. 交互与快捷操作 (Interactions & Shortcuts)

  • 键盘导航: 支持 J/K 等快捷键（若已配置）进行文章切换。
  • 标记管理:
    • 单击标记已读/未读。
    • 一键“全部标记为已读”（支持针对特定订阅源或文件夹执行）。
    • 星标收藏，方便日后回溯。

5. 数据分析仪表盘 (Analytics & Insights)

  • 阅读统计: 记录并展示不同时段（周/月/年）的总阅读时间。
  • 数据可视化: 通过图表展示阅读习惯（需结合项目中的 chart.js 组件）。
  • 来源分析: 通过 AnalysisController 分析订阅源的更新频率及内容偏好。

技术亮点 (Technical Highlights)

  • 后端: 基于 PHP + SQLite3，轻量且高效。
  • 前端: 原生 JavaScript (Vanilla JS) + CSS，无重型框架依赖，加载极快。
  • 优化: 数据库层面通过 JOIN 和 GROUP BY 优化了未读数统计性能。
 
 
About Xiaoyun
 
]]> <![CDATA[步行环游世界，走了近30年]]> http://www.ccyun.com/roadworld 2025-12-17T16:00:00.000Z
看这个新闻真的佩服，说到，然后去做到。
 
上个世纪90年代的一天，一个英国青年在酒吧里随口说，他可以从南美洲最南端一路走到英国。他的朋友都不信。
他就跟朋友打赌，他能做到。1998年，他正式从智利最南端开始步行，那一年他29岁。
notion image
27年过去了，他已经56岁了，依然在路上。
好消息是，他已经接近行程的尾段，预计将于2026年9月到达终点英国。
notion image
下面就是他的路线图，从南美洲最南端到北美洲最北端，再到亚洲和欧洲，最后是英国。
notion image
整个行程中，他只能步行或者游泳，不能使用任何交通工具。最难的一段就是北美洲与俄罗斯之间的白令海峡，为了不坐船，他是在冬天从海冰上爬过去的。
notion image
这27年中，他也不是每天都在走，有时因为各种原因，会离开一段日子，然后再回来接着走。
notion image
notion image
他说，依靠个人的力量不可能完成这样的行程，留不开家人的支持、陌生人的友善，以及赞助商的帮助。
至于是什么力量支撑他坚持走了近30年？他说："你需要看看真实的世界，以及生活在其中的人们，这将是你所能接受的最好的教育之一。"
notion image
 
 
About Xiaoyun
 
]]> <![CDATA[ 3D文字生成工具 - AI实践 ]]> http://www.ccyun.com/ai3dfont 2025-12-03T16:00:00.000Z
3D文字生成工具，可拆分笔画拖动布局，可自动旋转全屏作为屏保展示，可下载透明字，
网址 https://1photo1month.com/lab/ai7/3dfont/
notion image
 
About Xiaoyun
]]>