我最近使用 AI coding agent 的频率很高，Codex、Claude Code 之类的工具基本已经进入日常工作流。 刚开始用这类工具，很容易把它理解成“更聪明的自动补全”或者“能帮我写代码的聊天窗口”。但用得久一点以后，我越来越觉得，这种理解太小了。 AI Agent 真正改变的不是某一次代码生成，而是整个软件工作流里“上下文如何组织、任务如何拆分、审查如何发生、经验如何沉淀”的方式。...

过去说知识管理，很多时候说的是分类、归档、标签、搜索、双链、卡片笔记，或者某种更适合个人使用的笔记方法。 这些东西当然有价值。但最近我越来越觉得，AI 出现以后，知识管理这件事的意义正在发生变化。 它不再只是“我如何管理自己的资料”，而是在变成“人和 AI 如何持续协作”的接口层。 AI 最缺的不是答案，而是上下文 大模型并不缺表达能力，也不缺生成能力。真正缺的是稳定、准确、可追溯的上下文。 你问...

AI coding agent 用久以后，一个很具体的问题会出现：它在后台工作时，人应该怎样知道它现在处于什么状态？ 编辑器里的进度、终端里的输出、通知里的提示都能解决一部分问题。但这些界面往往要求你主动看过去。你如果正在处理别的事情，或者同时开着几个会话，很容易不知道哪个 agent 还在跑，哪个已经完成，哪个卡住了，哪个需要你确认。 vibe-lamp 这个项目就是从这个很小的问题开始的。 它...

很多产品一说 AI 原生，最后落到界面上就是多一个聊天框。 聊天框当然有用。它适合表达不确定的意图，也适合把复杂入口收敛成自然语言。但如果一个业务系统真正要被 AI 深度参与，聊天框只是最外层的交互形式，不是系统能力本身。 我在 LinchKit 上持续做的一些实验，核心其实不是“让 AI 多写一点代码”，而是另一个问题：业务系统内部的能力、规则和边界应该怎样表达出来。 规则、权限和状态必须先被表...

我过去看知识库，主要还是从人的角度看：资料能不能找到，笔记之间有没有关系，目录是不是清楚，长期回看时能不能想起当时为什么这么判断。 后来用 AI agent 做事多了以后，我对知识库的要求变了。 人看笔记时，可以容忍很多隐含信息。一个标题、一个标签、几句当时写给自己的话，过几个月再看，大概还能补回语境。但 AI 不一样。它不会自然知道哪份资料更可信，也不知道一段话是草稿、事实、规则、偏好，还是一次...

很多工具刚开始都不像一个“项目”。 它可能只是为了把一份数据清洗干净，或者为了让一个地址、行政区划、文档片段、表格文件变得更容易被程序读取。需求很小，边界也很窄，看起来不值得认真写。但这种小工具如果反复出现，就会慢慢变成个人工作流里的基础设施。 2026 年初我做 cpca-rs、cpca-linch 这一类东西时，感受就很明显。表面上它们只是和中文地址、行政区划解析有关的本地工具，但背后其实是同...

为了打造一个真正高效的生产力环境，我从零开始构建了这套 Hyprland 配置。本文将分享其中的核心功能、设计思路以及我是如何解决中文输入法等痛点的。

看到有人问大家的个人网站都是什么样的，想起来我这个站也运行一段时间了，拿出来晒晒。从技术选型到内容特色，从开源项目到AI协作，分享一个17年程序员的个人网站建设心得。

近期在做内部员工持股平台的设计，由此引发了一系列对公司现有绩效、激励等制度的思考：当绩效、激励、关怀沦为综合管理部的KPI，管理者正在逃避真正的责任

我以前介绍自己，最容易说的一句话是：我是一个全栈开发。 这句话当然没错。2008 年开始写程序，那时候很多小团队里并没有那么清楚的岗位边界。前端要写，后端要写，数据库要管，服务器要部署，客户说不清楚需求的时候也要去问。那时候不叫全栈，可能只是“美工也会一点、程序也会一点、电脑坏了也能看看”的那种人。 但到现在，如果还只用“全栈开发”来介绍自己，我会觉得不太准确。 不是因为这个词不够高级，而是因为它...

在十余年信息化系统建设的摸爬滚打中，我始终在寻找一种更通用、更可持续的方式去应对企业软件的复杂性。LinchKit 是我对这个问题长期思考与实践的汇总——它不仅是一个模块化的 TypeScript 开发框架，更是一套面向 AI 时代、服务于企业内控与数据驱动决策的底层平台构想。本文将分享它的背景、核心设计理念与未来方向。

在三方物流运营中，将运输任务分包给下游承运商虽常见，却也伴随着不小的法律与运营风险。本文梳理了三方物流企业在签署下游合同时应重点关注的几个要素，涵盖合同结构、资质审核、风险识别、现场考察、责任机制等方面，帮助从业者有效规避连带风险、提升风控能力。