<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://zhangsichu.com/</id><title>ZhangSichu</title><subtitle>ZhangSichu's Personal Blog.</subtitle> <updated>2026-06-23T14:34:08+08:00</updated> <author> <name>ZhangSichu</name> <uri>https://zhangsichu.com/</uri> </author><link rel="self" type="application/atom+xml" href="https://zhangsichu.com/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://zhangsichu.com/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 ZhangSichu </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>用 AI Agent 与知识库重塑遗留系统迁移范式</title><link href="https://zhangsichu.com/posts/reshaping-migrat-on-paradigm-of-legacy-cms-with-ai-agent/" rel="alternate" type="text/html" title="用 AI Agent 与知识库重塑遗留系统迁移范式" /><published>2025-12-27T10:01:31+08:00</published> <updated>2025-12-27T10:01:31+08:00</updated> <id>https://zhangsichu.com/posts/reshaping-migrat-on-paradigm-of-legacy-cms-with-ai-agent/</id> <content type="text/html" src="https://zhangsichu.com/posts/reshaping-migrat-on-paradigm-of-legacy-cms-with-ai-agent/" /> <author> <name>ZhangSichu</name> </author> <category term="Generative AI" /> <summary>本议题将深入剖析一个极具代表性的企业难题：如何高效、高质量地将一个运营超过 20 年的 CMS 系统迁移至新平台。 当原始代码和数据库已成“黑盒”且无法读取时，传统的 ETL(抽取 - 转换 - 加载) 工具和人工平移方法将面临巨大挑战， 不仅效率低下，且难以实现内容的结构化与美化升级。 针对这一痛点，本演讲将提出一个基于前沿大语言模型 (LLM) 驱动的创新解决方案。 我们利用 Langflow 作为可视化的 AI 工作流编排中枢，串联起多个 Agent 与外部工具 MCP， 构建了一个端到端的内容迁移自动化流水线。 核心挑战：从“黑盒”到“智能迁移” 传统方法的困境： 传统迁移方法需要耗时耗力地进行逆向工程，破解老旧系统的“黑盒”，成本高昂且风险大。 AI 解决方案：不破解代码和数据库，而将重点转移到用户可见的页面内容，将“代码结构”问题...</summary> </entry> <entry><title>CLI Blog 全新上线</title><link href="https://zhangsichu.com/posts/my-command-line-blog/" rel="alternate" type="text/html" title="CLI Blog 全新上线" /><published>2025-07-25T14:03:25+08:00</published> <updated>2025-07-25T14:03:25+08:00</updated> <id>https://zhangsichu.com/posts/my-command-line-blog/</id> <content type="text/html" src="https://zhangsichu.com/posts/my-command-line-blog/" /> <author> <name>ZhangSichu</name> </author> <category term="Web开发" /> <summary>欢迎来到 ZhangSichu’s CLI Blog 全新版本——一个以命令行为入口的博客体验空间，向 2007 年的原型致敬，同时注入现代前端技术与惊喜交互。点此感受 CLI Blog 体验地址 全新 CLI Blog 功能一览 新版 CLI Blog 拥有完整的命令行体验，同时在界面交互、性能、用户体验上全面升级。以下是详细功能： 命令 (alias) 参数 功能说明 help, h, ? — 显示帮助说明 gui, startx — 切换回图形界面浏览器 ls, dir, list — 列出所有文章（按 ID、日期排序） ...</summary> </entry> <entry><title>最近两次的GenAI社区活动</title><link href="https://zhangsichu.com/posts/the-two-recent-gen-ai-community-events/" rel="alternate" type="text/html" title="最近两次的GenAI社区活动" /><published>2025-05-30T23:16:52+08:00</published> <updated>2025-05-30T23:16:52+08:00</updated> <id>https://zhangsichu.com/posts/the-two-recent-gen-ai-community-events/</id> <content type="text/html" src="https://zhangsichu.com/posts/the-two-recent-gen-ai-community-events/" /> <author> <name>ZhangSichu</name> </author> <category term="Generative AI" /> <summary>GDG - AI编码助手到底能让软件交付快多少？ 声称AI编码助手可以将交付速度提高 50% 是夸大其词。我们的测试表明，增幅更有可能是 10-15%。但这仍然是一个显著的增幅，而且考虑到市场上的 AI编码助手的当前价格，性价比极高。 在讨论AI编码助手对软件交付团队的影响时，主要衡量指标是速度。虽然速度可能被称为生产力，但在大多数情况下，人们真正想表达的是“我们快了多少？”这就是为什么关于生产力提高的问题的预期答案通常是一个百分比值。然而，尽管行业炒作始于 50% 的生产力提高，但人们的想法似乎已经转向了另一个极端，人们谈论的是生产力完全没有提高，相反，错误率增加了 41%。 虽然将生产力与速度等同起来肯定是有争议的，但我们不想在这里探讨这个问题。本次Session我们将专门研究AI编码助手如何提高速度。确实，速度本身可能很难确定；然而，在软件交付的背景下，我们拥有的速度的最...</summary> </entry> <entry><title>将安全内建于开发流程中：威胁应对分步指南 (Build Security In) - 下</title><link href="https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-two/" rel="alternate" type="text/html" title="将安全内建于开发流程中：威胁应对分步指南 (Build Security In) - 下" /><published>2025-05-29T22:32:51+08:00</published> <updated>2025-05-29T22:32:51+08:00</updated> <id>https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-two/</id> <content type="text/html" src="https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-two/" /> <author> <name>ZhangSichu</name> </author> <category term="软件工程" /> <summary>上篇中，咱们解释了什么是威胁，列举了常见的安全威胁，引入了“威胁四象限分类法”，将威胁分为开发人员相关和系统开发相关。针对性的讨论了开发人员相关的安全威胁，强调了通过工具与流程自动化以及将安全意识融入日常工作的重要性。本篇咱们将继续讨论如何应对系统开发相关的安全威胁。 三、应对策略：针对性解决 3.2 系统开发相关的安全威胁应对策略 软件系统开发过程中相关的安全威胁多源于系统设计、架构实现或基础设施层面的不当决策，这类问题一旦产生，影响范围广，回滚成本高。应对这类威胁的策略需围绕 设计前置、评审规范、持续建模与自动化防御四个方面进行。 3.2.1 风险识别前移至故事卡片级别 在 Backlog Grooming 阶段加入“安全影响评估”环节：安全冠军或资深开发协助识别本卡片可能带来的系统性安全风险。 标记具有“外部影响面”的卡片为“需安全建模”，例如： ...</summary> </entry> <entry><title>将安全内建于开发流程中：威胁应对分步指南 (Build Security In) - 上</title><link href="https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-one/" rel="alternate" type="text/html" title="将安全内建于开发流程中：威胁应对分步指南 (Build Security In) - 上" /><published>2025-05-28T23:19:32+08:00</published> <updated>2025-08-08T12:51:52+08:00</updated> <id>https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-one/</id> <content type="text/html" src="https://zhangsichu.com/posts/a-step-by-step-guide-to-threat-response-one/" /> <author> <name>ZhangSichu</name> </author> <category term="软件工程" /> <summary>在你的研发团队中，什么才构成“安全威胁”？又该如何有效地识别、分类并应对这些威胁？每个人都希望保障团队、系统和服务的安全，然而由于这个话题过于庞大且令人望而生畏，同时过往的讨论和研究成果离工程团队的日常工作依然存在结合不足的情况。本文将帮助你把安全威胁拆解为一系列可管理的步骤，从理解威胁、分类威胁，到有效地应对它们。我们从一个问题开始吧。 一、什么是威胁？ 威胁的类型和严重程度往往取决于具体的上下文和视角，不同的研发团队可能得出大相径庭的结论。现实工作中存在的威胁多种多样，举几个常见的例子： 明文凭证存储: 密码、API 密钥或私钥被以明文形式保存在代码、配置文件甚至个人笔记中，极易被窃取和滥用。 CI/CD ① 凭证暴露: 构建流水线的日志中输出了服务账户的访问令牌或密钥，任何有权限查看日志的人员都可能无意间获取这些敏感信息。 脚本误操作: 自动化脚本缺乏验证与...</summary> </entry> </feed>
