我是一名长期从事软件研发与系统设计的工程师。
我更关心复杂系统如何被正确建模、拆解与长期演化，而不只是把功能“做出来”。
在过去的多年工作中，我持续在以下问题上投入精力与思考：
- 分布式系统如何避免演变为不可理解的工程拼装体
- 任务、流程、状态与资源之间的结构性关系
- 软件架构中“控制”“反馈”“约束”的真实含义
- 人、工具与自动化系统之间的边界应当如何划分
- 新一代 AI / LLM 应该被当作什么样的系统组件来使用
我长期围绕任务软件框架、流程编排（DAG）、控制与调度展开实践与抽象。
相关关键词包括但不限于：
- Controller / Agent 架构
- 任务状态机与生命周期管理
- DAG 驱动的任务编排
- 边缘节点与中心系统的协同
- 离线 / 弱网络环境下的系统可用性
我更关注结构是否自洽，而不仅是功能是否可用。
我对系统论、控制论、信息论在工程实践中的落地方式保持长期兴趣。
在软件设计中，我倾向于思考：
- 状态是否被显式建模
- 反馈回路是否清晰
- 系统是否存在隐含的“失控路径”
- 复杂性是否被推迟或被真正消解
我认为很多“难以维护的软件”，本质上是未被承认的系统问题。
我并不执着于某一种语言或技术栈，而更在意它们所处的系统层级：
- C++：贴近系统边界、性能与确定性
- Go：工程化的并发与服务构建
- Qt：复杂工具型软件与人机界面
- gRPC / Protobuf：明确的系统契约
- Linux / Networking：系统真实行为的发生地
工具只是载体，结构才是核心。
-
Plum（进行中）
一个围绕分布式任务编排、控制与资源协同的系统性探索项目
（包含 Controller / Agent 架构、DAG 任务模型、C++ / Go 组件等） -
一系列用于理解与验证系统行为的工具型仓库
包括协议分析、路径表达、配置抽象、系统边界实验等
其中不少项目仍处在“探索态”，这对我来说是一个正常且必要的状态。
- 偏好从系统结构而非局部技巧理解问题
- 警惕“短期可交付、长期不可维护”的设计
- 相信抽象不是为了优雅，而是为了降低认知负担
- 对“黑箱式解决方案”保持谨慎态度
- 更重视长期演化能力，而非一次性交付
- 多年软件研发经验
- 长期自我学习与跨领域探索
- 对“为什么这样设计”有执念
- 习惯将零散知识整理为可复用的认知结构
这个仓库中的内容，更多是思考的痕迹，而不是结论的集合。
路漫漫其修远兮，吾将上下而求索
—— 这不是口号，而是一种工作方式