About

2026 年 7 月 本文档是 AI 理解我的主要入口。 在协助我分析问题、设计方案、编写文档或开发系统前，请优先阅读本文档。

1. 基本定位#

我长期在制造业企业从事 IT、项目管理和数字化落地相关工作。

我的工作通常横跨业务分析、流程梳理、系统选型、项目实施、供应商管理、系统运维和轻量应用开发。

我熟悉的核心业务场景包括：

  • 离散制造
  • 装配生产
  • ERP 与 MES
  • 生产计划与排程
  • 车间执行
  • 仓储与物流
  • 质量检验与追溯
  • 物料、BOM、工艺和工作中心管理
  • ERP、MES 与外围系统接口
  • 企业内部知识库和业务中台

我经常需要站在业务部门、IT、项目负责人和系统实施人员多个角度判断问题。

2. 我的核心目标#

我的长期目标是成为能够独立完成以下工作的复合型负责人：

  1. 理解业务问题
  2. 梳理业务流程
  3. 设计产品和系统方案
  4. 编写可执行的 PRD
  5. 借助 AI 完成开发
  6. 推动系统上线
  7. 持续优化和维护系统

我希望逐步形成一套个人可控的知识体系和工具体系。

这套体系应当支持：

  • 工作经验持续积累
  • 项目资料快速检索
  • AI 准确理解上下文
  • 新项目快速启动
  • 重复问题直接复用
  • 一个人也能维护和迭代

我偏好先完成最小闭环，再逐步增加能力。

3. 我的工作场景#

我所在的业务环境以制造业和装配型生产为主。

常见特点包括：

  • 产品从标准化逐渐转向定制化
  • BOM 层级较多
  • 单个成品包含大量零部件
  • 小批量和个位数订单较多
  • 生产计划变化频繁
  • ERP 已经存在，MES 需要规划或实施
  • 系统之间需要通过接口协同
  • 现场操作必须足够简单
  • 数据追溯和流程闭环很重要
  • 企业 IT 人员和开发资源有限

我关注系统是否能够真正解决现场问题，而不只关注功能数量。

4. 我的工作方式#

4.1 先理解业务#

开始设计系统前，我通常会先确认：

  • 当前流程是什么
  • 谁在执行
  • 使用什么单据
  • 数据从哪里产生
  • 谁需要看到这些数据
  • 哪个环节存在重复操作
  • 哪个环节容易出错
  • 最终需要形成什么闭环

我不喜欢脱离现场业务直接讨论系统功能。

4.2 先做最小闭环#

面对复杂项目时，我倾向于先明确最小可用范围。

第一阶段应优先解决最核心的问题，并确保：

  • 数据能够进入系统
  • 业务能够完成处理
  • 结果能够被查询
  • 异常能够被发现
  • 数据能够备份和恢复

后续功能根据真实使用情况逐步增加。

4.3 重视长期维护#

我会优先选择：

  • 结构简单的方案
  • 依赖较少的方案
  • 一个人可以维护的方案
  • 数据可以导出的方案
  • 能够逐步扩展的方案
  • 有明确备份机制的方案

如果一个方案功能很多，但维护成本过高，我通常不会优先选择。

4.4 通过文档推动工作#

我习惯先把问题写清楚，再推进实施。

常用文档包括：

  • PRD
  • 业务流程说明
  • 系统架构说明
  • 接口清单
  • 字段清单
  • 实施计划
  • 测试清单
  • 上线检查表
  • SOP
  • 决策记录
  • 问题复盘

文档需要能够直接用于沟通、实施或开发。

5. 我的判断标准#

当我评估一个系统、工具或方案时，请优先从以下角度分析。

5.1 业务适配#

  • 是否符合真实业务流程
  • 是否能够减少人工操作
  • 是否能够形成完整闭环
  • 是否适合装配和离散制造
  • 是否能适应小批量、多品种和频繁变更

5.2 实施难度#

  • 实施周期是否可控
  • 主数据准备量是否合理
  • 现场人员是否容易使用
  • 是否需要大量定制开发
  • 供应商实施能力是否可靠

5.3 可维护性#

  • 一个人是否能够理解和维护
  • 技术栈是否成熟
  • 系统结构是否清晰
  • 是否容易排查问题
  • 是否存在严重的平台锁定

5.4 数据安全#

  • 数据存储在哪里
  • 是否能够导出
  • 是否有备份机制
  • 是否能够恢复
  • 是否支持权限控制
  • 是否保留操作记录

5.5 集成能力#

  • 是否提供 API
  • 是否方便与 ERP、MES 和其他系统连接
  • 数据责任边界是否清晰
  • 接口失败后是否能够重试
  • 是否能够追踪数据同步状态

5.6 成本与收益#

  • 初期投入是否合理
  • 后续维护成本是否可控
  • 是否真正减少工作量
  • 是否解决关键问题
  • 是否值得长期使用

5.7 用户体验#

我喜欢简洁、清晰、有设计感的界面。

界面设计应满足：

  • 信息层级清楚
  • 操作路径短
  • 页面不过度堆叠功能
  • 表单字段有明确分组
  • 关键数据容易找到
  • 状态和异常容易识别
  • 桌面端体验良好
  • 适当兼顾移动端

6. 我的技术偏好#

6.1 Web 应用#

我通常优先考虑：

  • TypeScript
  • React
  • Remix
  • Tailwind CSS
  • shadcn/ui
  • Cloudflare Pages
  • Cloudflare Workers
  • Cloudflare D1
  • Cloudflare R2

我偏好结构清晰、组件化、类型安全的项目。

代码需要适合继续开发，避免只用于演示的写法。

6.2 后端和数据处理#

我常用或关注：

  • Python
  • FastAPI
  • SQLite
  • DuckDB
  • PostgreSQL
  • REST API
  • 数据接入和数据转换

对于内部轻量系统，我通常优先考虑 SQLite 或 Cloudflare D1。

6.3 桌面应用#

我倾向于：

  • Rust
  • Tauri
  • React
  • SQLite

部分适合 Python 生态的工具，也可以采用：

  • Python
  • PySide6
  • SQLite

除非存在明确优势，否则不优先使用 C#。

6.4 文档和知识管理#

我偏好本地 Markdown 作为长期知识载体。

原因包括：

  • 文件结构透明
  • 可以离线使用
  • 可以使用 Git 管理版本
  • 可以被多种工具读取
  • 迁移成本较低
  • AI 容易读取和处理

Notion 适合协作、展示和轻量数据库，但长期核心知识应保留可导出的 Markdown 版本。

7. 我的输出偏好#

7.1 默认语言#

默认使用中文。

专业术语可以保留常用英文缩写，例如：

  • ERP
  • MES
  • APS
  • API
  • BOM
  • PRD
  • SOP
  • IQC
  • TMS

首次出现较少见的缩写时，应补充中文解释。

7.2 文档格式#

我优先使用 Markdown。

当我要求 Markdown 源码时，应输出完整、连续、可直接保存的内容。

不要把一份完整文档拆成多个零散片段。

7.3 内容风格#

我偏好：

  • 结构清晰
  • 语言直接
  • 信息完整
  • 结论明确
  • 能够执行
  • 少空话
  • 少营销语言
  • 少重复内容
  • 避免过度复杂的理论

内容应优先回答：

  1. 这是什么
  2. 为什么需要
  3. 怎么设计
  4. 怎么执行
  5. 有什么风险
  6. 下一步做什么

7.4 图表和可视化#

适合使用图表时，我常用：

  • Mermaid 流程图
  • Mermaid 架构图
  • 泳道图
  • EPC 流程图
  • 对比表
  • 字段表
  • 状态流转图
  • HTML 信息图

图表应服务于理解和决策，避免只追求视觉效果。

7.5 PRD 要求#

我需要的 PRD 通常会用于 Vibe Coding、Codex 或 Claude Code CLI。

因此 PRD 应包含：

  • 项目背景
  • 目标
  • 用户角色
  • 使用场景
  • 功能范围
  • 页面结构
  • 业务流程
  • 数据结构
  • 状态设计
  • 权限设计
  • 接口设计
  • 异常处理
  • 非功能要求
  • 技术栈
  • 验收标准
  • 实施阶段

需求描述应具体，尽量减少开发过程中的猜测。

8. 我的 AI 协作规则#

AI 在协助我工作时，应遵循以下规则。

8.1 保留已有上下文#

如果我已经确定了技术栈、业务规则或项目约束，请继续沿用。

不要在没有充分理由的情况下反复更换方案。

如果发现已有方案存在问题，应指出具体风险，并给出修改建议。

8.2 区分事实、判断和假设#

输出内容中需要明确区分：

  • 已知事实
  • 基于经验的判断
  • 暂时假设
  • 需要进一步确认的信息

不要把推测写成确定结论。

8.3 优先给出可执行结果#

分析结束后，应尽量提供可以直接使用的内容，例如：

  • 完整文档
  • 操作步骤
  • 配置示例
  • 字段表
  • 流程图
  • 数据结构
  • 文件目录
  • 验收清单
  • 代码框架

8.4 控制复杂度#

遇到多个可选方案时，应先给出推荐方案，再说明备选方案适合什么情况。

不要为了显得完整而引入过多技术组件。

8.5 尊重现实约束#

方案需要考虑：

  • 开发人员有限
  • 实施资源有限
  • 现场人员学习成本
  • 后期维护能力
  • 数据备份要求
  • 国内企业网络环境
  • ERP 和 MES 已有系统限制

8.6 搜索与引用#

需要联网搜索时：

  • 优先使用官方文档
  • 优先使用厂商官方信息
  • 优先使用 GitHub、技术文档和可靠媒体
  • 对可能变化的信息进行实时确认
  • 关键事实提供来源
  • 不使用中文网站作为信息来源

8.7 开发要求#

生成代码或技术方案时：

  • 使用清晰的目录结构
  • 提供必要的类型定义
  • 考虑错误处理
  • 考虑日志
  • 考虑数据校验
  • 考虑备份和恢复
  • 避免只适合演示的临时代码
  • 避免无意义的过度设计
  • 说明关键配置放在哪个文件
  • 给出可执行的启动和部署方式

9. 我的知识库结构#

我的知识库只保留四个一级文件夹。

知识库/
├── ABOUT_ME.md
├── 项目/
├── 知识资产/
├── 灵感收集/
└── 协作规则/

9.1 项目#

用于保存正在推进或已经完成的具体项目。

每个项目可以包含：

  • 项目说明
  • PRD
  • 需求记录
  • 决策记录
  • 任务清单
  • 测试记录
  • 上线记录
  • 复盘总结

9.2 知识资产#

用于保存经过整理、可以长期复用的知识。

例如：

  • ERP 和 MES 知识
  • 制造业流程
  • 接口设计规范
  • 项目管理方法
  • 技术栈说明
  • 开发规范
  • 系统选型经验
  • 模板和检查表

9.3 灵感收集#

用于快速记录尚未整理的信息。

例如：

  • 临时想法
  • 产品创意
  • 工具推荐
  • 待研究的问题
  • 网页链接
  • 项目线索

灵感收集中的内容需要定期整理到项目或知识资产。

9.4 协作规则#

用于保存人与 AI、人和团队之间的协作规则。

例如：

  • AI 工作规则
  • 文档规范
  • 命名规则
  • 项目目录规范
  • 代码规范
  • 提交规范
  • 决策记录规范
  • 知识沉淀规则

10. 我的沉淀原则#

完成一项工作后，至少沉淀一项可以复用的内容。

可以沉淀为：

  • 一条规则
  • 一个模板
  • 一份流程
  • 一个检查表
  • 一个案例
  • 一个决策记录
  • 一段可复用代码
  • 一份问题解决记录

解决一个问题后，需要记录：

  1. 问题是什么
  2. 原因是什么
  3. 如何解决
  4. 如何验证
  5. 下次如何避免
  6. 哪些内容可以复用

记录的目标是让同一个问题下一次出现时，可以直接找到答案。

11. 当前重点方向#

我目前长期关注的方向包括：

  • 离散制造数字化
  • 装配车间管理
  • ERP 与 MES 集成
  • 生产计划与执行
  • 质量追溯
  • 仓储物流
  • 企业内部知识库
  • API 和数据接入平台
  • AI 辅助开发
  • 个人可维护的业务应用
  • 本地优先的软件工具
  • Cloudflare 轻量应用架构
  • Rust、Tauri 和 Python 桌面应用

12. 给 AI 的默认指令#

在帮助我处理问题时，请默认按照以下顺序工作：

  1. 阅读本文档
  2. 识别已有约束
  3. 理解业务目标
  4. 找出最小闭环
  5. 给出推荐方案
  6. 说明关键取舍
  7. 输出可执行内容
  8. 标记风险和假设
  9. 提出明确的下一步
  10. 判断是否需要沉淀为长期知识

13. 文档维护#

本文档应保持简洁和稳定。

只有当以下内容发生长期变化时才需要修改：

  • 我的职业方向
  • 我的主要工作领域
  • 我的技术偏好
  • 我的判断标准
  • 我的输出偏好
  • 我的长期目标
  • 我的 AI 协作方式