途中书写：为什么要做这个公众号

很多公众号都有一个明确的标签。

有人写职场，有人写技术，有人写商业，也有人专门分享某个行业的知识。

但最初建立这个公众号时，我并没有想得那么完整。

那时候只是觉得，工作中遇到的问题越来越多，做过的项目越来越杂，很多曾经花费大量时间研究、测试和解决的事情，过一段时间之后，只剩下电脑里的几份文档、聊天记录里的几张截图，以及一些已经逐渐模糊的记忆。

有些问题解决过，却没有真正沉淀下来。

有些经验积累了，却没有形成可以重复使用的方法。

有些想法曾经很清晰，却因为没有及时记录，最终消失在日常工作里。

于是，我开始写。

这个公众号，也就这样出现了。

为什么叫“途中书写”

“途中”并不是一个终点。

它代表一种状态：很多事情仍在进行，很多问题还没有标准答案，很多计划也只是刚刚开始。

信息化建设在途中。

对人工智能的理解在途中。

产品开发在途中。

创业尝试在途中。

个人成长同样在途中。

过去，我总觉得应该等到一件事情彻底完成、一个问题完全想清楚、一个项目取得足够漂亮的结果之后，再把它写出来。

后来才发现，真正有价值的内容，往往并不只存在于最终结果里。

一次系统上线为什么失败，一个需求为什么反复修改，一个技术方案为什么在测试环境正常，到了生产环境却出现问题，一款产品为什么最初设想得很好，真正开发时却不得不不断调整。

这些过程中的判断、犹豫、试错和修正，可能比最后那张“项目成功上线”的截图更值得记录。

所以，这里不是成功经验的陈列馆，也不是标准答案的集合。

它更像一本持续更新的工作笔记。

记录正在经历的事情，也记录事情发生之后留下的思考。

这就是“途中书写”。

从信息化工作开始

这个公众号最初的内容，大多来自企业信息化工作。

在企业里做信息化，很难只关注某一项技术。

需要理解业务流程，需要面对财务、人力、供应链、生产、设备、客户和管理层；需要处理系统建设、数据治理、权限设计、接口集成、项目推进以及各种临时出现的问题。

很多时候，信息化部门看起来是在建设系统，实际上是在协调业务、流程、数据和组织之间的关系。

一套系统是否成功，并不只取决于代码是否正确。

一个项目是否能够落地，也不只取决于软件功能是否完整。

系统背后是业务，业务背后是组织，组织背后又是不同岗位、不同部门和不同目标之间的协作。

因此，这里会持续记录企业信息化中的真实问题。

例如，为什么企业系统越建越多，管理反而越来越混乱；为什么投入大量资金建设平台，最终仍然依赖Excel；为什么数据中台、主数据、业财一体化听起来都很重要，真正实施时却困难重重；为什么信息化部门承担了大量工作，却依然很难进入企业的核心决策。

这些文章不只是介绍概念。

更希望从实际场景出发，讨论问题是怎样产生的，背后的本质是什么，以及企业真正落地时需要面对哪些限制。

技术不是目的，但技术值得被认真记录

在信息化工作之外，这里也会记录具体的技术实践。

包括服务器部署、开源软件、数据库优化、系统集成、自动化脚本、网络故障、打印服务、远程运维，以及各种看起来不大，却可能消耗半天甚至几天时间的问题。

很多技术问题最终的解决方法可能只有一条命令、一个配置项或者几行代码。

但找到这条命令之前，往往经历了大量排查。

真正值得记录的，不只是最终答案，还有排查过程中的判断：

问题最初是如何发现的，哪些方向被证明是错误的，哪些日志提供了关键线索，为什么最终采用这个方案，以及这个方案还有什么风险。

技术文章最容易变成命令和步骤的堆砌。

但相比直接复制一段代码，我更希望说明它为什么有效，又适用于什么环境。

技术会更新，工具会变化，命令也可能失效。

但分析问题的方法，可以保留更久。

人工智能正在改变很多事情

人工智能是这个公众号未来会长期关注的另一条主线。

过去一段时间，AI已经从一个偶尔使用的工具，逐渐进入写作、开发、数据分析、产品设计和企业管理。

它可以帮助生成代码、整理需求、分析文档、设计流程，也可以与企业中的ERP、CRM、OA、BI等系统结合，成为新的业务入口。

但AI带来的并不只有效率提升。

它也会重新定义很多岗位的工作方式，改变企业建设系统的方法，甚至改变信息化部门本身的职责。

未来，企业可能不再只是让员工进入多个系统寻找数据，而是直接向AI提出问题，由AI自动调用系统、查询数据、完成分析并给出结果。

信息化部门也可能从过去的系统建设者，逐渐转变为数据、流程、工具和智能能力的组织者。

这些变化仍在发生，没有人能够给出全部答案。

因此，这里不会只追逐新的模型和热门名词，也不会简单讨论“AI会不会取代某个岗位”。

更关注的是，AI在真实企业中能解决什么问题，怎样接入现有系统，怎样控制权限和数据安全，又怎样从演示效果走向长期使用。

从记录工作，到尝试做产品

写作过程中，我也开始尝试把一些想法真正做成产品。

从一个简单的小程序，到CRM、开源项目体验平台、学习工具，再到围绕企业服务展开的一些尝试。

这些产品可能并不成熟，也不一定都会成功。

有些想法在开发后会被证明需求不足，有些功能做出来之后才发现设计并不合理，有些产品可能投入了很多时间，最终仍然没有获得预期的用户。

但这同样是“途中”的一部分。

做产品让我更加清楚地认识到，从一个想法到真正可用，中间存在巨大的距离。

技术实现只是其中一环。

还需要考虑用户需求、交互设计、产品定价、部署方式、服务能力、合规要求和长期维护。

过去站在企业甲方的角度，更关注系统能否满足业务需求。

当真正开始做自己的产品之后，也逐渐理解了乙方、开发者和产品团队面对的限制。

因此，“途中书写”也会记录这些产品背后的过程。

包括一个想法是怎样出现的，功能怎样取舍，开发中踩过哪些坑，为什么调整方向，以及一个普通的小团队如何尝试将产品真正推向市场。

不包装结果，也不刻意放大成绩。

只是如实记录一件事情从无到有的过程。

为什么坚持公开写出来

很多内容完全可以只保存在个人笔记里。

但公开写作和私人记录并不相同。

个人笔记可以只写几个关键词，因为只有自己需要看懂。

公开文章则要求把事情重新梳理清楚，让背景、逻辑和结论能够被其他人理解。

这个过程会迫使自己重新思考：

这个问题真的理解了吗？

这个结论是否只是个人经验？

有没有忽略其他可能性？

提出的方案是否真的能够落地？

写作不仅是输出，也是一次重新整理认知的过程。

同时，我也希望这些内容能够帮助到一些正在经历相似问题的人。

也许某篇数据库优化文章，能够减少一次漫长的排查。

也许某篇信息化项目复盘，能够让一个团队提前发现风险。

也许某个开源工具的部署记录，能够让一家小企业用较低的成本解决实际问题。

一篇文章不一定能提供完整答案。

但只要能够带来一个思路，减少一点重复试错，就已经有了价值。

这里不会只写“正确的事情”

互联网上并不缺少观点鲜明、结论确定的文章。

但真实工作中，很多事情并没有那么确定。

同一个系统，在一家企业可能取得成功，放到另一家企业却可能完全失败。

同一种管理方法，在一个阶段有效，到了另一个阶段也可能成为限制。

很多文章习惯从结果倒推过程，把所有选择描述成提前设计好的正确路线。

但现实中的项目往往不是这样。

它充满临时变化、信息不足和有限条件下的选择。

所以，这里也会保留一些不成熟的判断。

某些观点可能会随着经验增加而改变，某些方案可能在后来被更好的方法替代。

这并不矛盾。

记录变化本身，也是写作的意义。

今天认为正确的事情，未来可能会重新审视。

曾经踩过的坑，也可能成为后来判断问题的基础。

写给同行，也写给未来的自己

“途中书写”首先是一份长期记录。

记录做过的项目、解决过的问题、产生过的想法，也记录一个信息化从业者在AI时代的观察与尝试。

它写给正在做企业信息化的人。

写给负责技术、系统、数据和项目，却经常难以解释自身价值的人。

写给正在尝试使用AI改进工作的人。

写给想做产品、做工具、做一点属于自己事情的人。

当然，它也写给未来的自己。

几年之后重新回看，或许会发现曾经的很多判断并不成熟，很多问题也已经有了新的解决方式。

但至少能够看到，这一路是如何走过来的。

写在最后

做这个公众号，不是因为已经抵达了某个终点。

恰恰是因为还在路上。

仍然在工作中遇到问题，仍然在学习新的技术，仍然在尝试新的产品，也仍然在寻找信息化、人工智能和个人成长之间更多的可能性。

这里不会永远只写一个领域，也不会刻意追求每篇文章都给出宏大的结论。

有时是一项企业信息化建设的思考。

有时是一次技术故障的处理记录。

有时是一个产品从想法到上线的过程。

有时也只是某个阶段留下的一点感受。

途中不是等待抵达的空白，而是人生真正发生的地方。

所以，我选择在途中记录，在途中思考，也在途中继续向前。

欢迎来到《途中书写》。

这里记录的，不只是答案。

还有寻找答案的过程。