ZDREAM - Thassarian 的个人博客
对抗变化的方法唯有拥抱变化。
目 录CONTENT
以下是
Thassarian
的文章
-
-
-
-
-
-
-
项目沟通提效：利用AI+Vue快速构建高保真Demo 我当前负责的平台项目，由于处于长期的运维与改造迭代阶段，团队架构相比建设期要精简许多。项目现场长久以来都是产品经理角色缺失、开发资源远程化的现实挑战。特别是在涉及旧有逻辑改造或复杂交互的新需求时，传统的“文字需求文档 + 静态线框图”的沟通模式，往往存在明显的信息折损。面对对业务背景不熟悉的远程开发人员，或是刚接手项目的技术伙伴，仅凭文档很难准确传达诸如“联动筛选”、“异步数据加载状态”等动态逻辑。这直接导致了开发产物与需求预期的偏差，进而引发多轮返工，增加了项目的时间成本。近期，尝试在需求分析阶段引入“高保真Demo”机制，利用 AI 辅助编码能力结合 Vue 框架，快速构建可交互的前端原型，以此替代传统的静态原型设计。这并非是为了越俎代庖去写代码，而是为了在需求传递环节实现“所见即所得”。一、 从静态文档到动态交互的转变传统的运维改造需求，往往卡在“逻辑复现”上。比如一个数据审批流程的改造，涉及多层级的状态判断。如果只是口头描述或画静态图，开发人员很容易忽略掉某些中间状态（如Loading时的按钮置灰、错误回显的格式等）。利用 Vue3 搭建一个轻量级的演示环境，并不需要构建完整的后端逻辑。通过 Mock 数据（模拟数据），就能把页面逻辑跑通。在这个过程中，大语言模型（LLM）成为了核心生产力工具。我不需要花费大量时间调整每一个 CSS 属性或 API 写法，只需将脑海中的业务逻辑拆解为具体的 Prompt（提示词）。例如：“生成一个基于 Element Plus 的表单，包含三个级联选择器，当第二个选择器选中‘异常’时，底部出现红色的备注必填框”。AI 能在几秒钟内生成可运行的代码片段。我所需要做的，是将这些片段组装、微调，并注入实际的业务模拟数据。二、 降低理解门槛，减少“解释成本”这种方式最大的收益在于沟通效率的提升。当需要向远程的后端开发解释一个复杂的接口传参逻辑时，直接把 Demo 里的 network 请求参数截图发过去，比写几百字的文档要直观得多。当需要让新来的前端开发调整页面布局时，直接把 Demo 的源码文件发给他作为参考，他只需要在此基础上进行工程化规范和接口对接即可，核心的交互逻辑已经通过代码的形式“固化”下来了。对于业主而言，他们往往对技术文档不感兴趣，但对“能点的页面”反馈非常直接。在正式开发介入前，拿着高保真 Demo 给业主演示，能提前发现流程上的不合理之处，避免了“开发完了才发现想要的不一样”这种最糟糕的情况。三、 边界与思考：PM的技术“度”作为项目经理，深入代码细节并不是为了替代开发人员。恰恰相反，这种做法是为了更好地服务于项目管理。* 明确边界：Demo 仅用于演示和逻辑确认，代码质量无需达到生产标准，不涉及复杂的鉴权、性能优化等后端问题。* 标准化思维：在构建 Demo 的过程中，其实是对业务流程进行了一次深度的“标准化预演”。我个人的习惯是喜欢把逻辑梳理得非常详尽，这种强迫症式的细节把控，通过代码逻辑的严密性得到了很好的安放。* 填补空缺：在团队配置不完整（如缺乏专职交互设计师或产品经理）的情况下，PM 具备一定的技术栈和工具使用能力，能够有效填补角色真空，保证项目的推进速度。转行软件行业六年有余，从早期的 ERP 实施到如今的大数据平台管理，技术一直在变，但解决问题的核心逻辑不变。通过 Docker 快速部署环境、利用 R 语言做数据分析验证、或是用 Vue 做原型，本质上都是为了在有限的资源下，寻找最优的解决方案。在AI技术日益成熟的当下，技术门槛在降低。对于管理者而言，重要的或许不再是“由于我不会写代码，所以我只能写文档”，而是“我知道如何利用技术工具，以最低的成本把我的想法准确无误地传递给团队”。这大概也是一种基于数字化手段的降本增效实践。
-
解决MD文件图片资源失效问题的一种实践：PicGo + 阿里云OSS 背景Markdown（简称MD）是一种轻量级标记语言，凭借其简洁的语法和对纯文本的专注，在技术文档撰写、笔记记录等场景下得到了广泛应用。它允许我们将格式与内容分离，最终可以轻松转换为HTML、PDF等多种格式，极大提升了内容创作的效率。 然而，便利性的背后也存在一个常见问题。当我们在本地使用Markdown编辑器（如Typora）写作时，插入的图片通常是引用的本地路径。这意味着，如果我们将这个.md源文件单独发送给他人，或者发布到不支持本地上传的平台，对方打开时所有的图片都将无法显示。传统的解决方法，如将文档导出为不可编辑的PDF，或者将.md文件和图片文件夹一起打包发送，都显得不够优雅和高效。 要从根本上解决这个问题，就需要引入“图床”的概念。简单来说，图床就是一个专门用来存储图片的网络服务器。我们将图片上传到图床，它会返回一个公开的URL链接。在Markdown文档中，我们用这个URL替换本地图片路径，这样无论文档在哪里被打开，只要有网络连接，图片就能被正确加载。 其实最初是想折腾一下自建图床的，也研究了一些开源方案，比如功能强大的S3兼容对象存储 MinIO，或是专门的图床程序如 hevereto 等，可以通过 Docker 方便地部署在自己的服务器上，数据的完全私有化也很有吸引力。不过，考虑到很多文档和图片资源需要在一些重要场合使用（比如面向业主的汇报材料或是大型培训的讲义），长期使用的稳定性、图片的访问速度就成了必须优先考虑的因素。自建服务固然有掌控数据的乐趣，但也意味着要自己承担网络波动、硬件故障等潜在风险。恰好当时阿里云在做活动，“OSS标准存储包”40GB一年的费用仅为9元，综合考量下来，这个成本远低于自己维护一台服务器的精力开销。最终，还是选择了阿里云OSS作为更稳妥的方案。注意！使用OSS时要注意防止流量盗刷。之前关注的某博主就因OSS存储桶（Bucket）的公网访问权限配置不当，被恶意程序在短时间内刷掉了巨额流量，据说是一周被刷掉了几万块。因此，在开通OSS后，务必第一时间在费用中心设置一个消费预算告警，例如每月消费超过10元就发送短信或邮件提醒，并设置封顶阈值，尽量规避风险。配置 有了存储图片的仓库，下一步就是如何让写作流程自动化，实现“图片即插即用、自动上传”的无缝体验。这里采用的组合是 Typora + PicGo。 PicGo是一个开源的图床上传工具，它像一个中转站，可以接收来自剪贴板或本地文件的图片，然后根据配置好的插件，将其自动上传到指定的图床（如阿里云OSS、腾讯云COS等），并返回相应格式的链接。 配置过程很直接：安装PicGo：从其官网或GitHub仓库下载并安装客户端。配置PicGo的阿里云OSS插件：在PicGo的“插件设置”中搜索并安装aliyun-oss插件。在“图床设置”中找到“阿里云OSS”，并填写配置信息。这些信息都可以在阿里云的控制台找到：keyId 和 keySecret：访问控制（RAM）中创建的AccessKey，建议授予仅有OSS写入权限的子账户，以实现权限最小化。存储空间名 (Bucket)：你创建的OSS存储桶名称。存储区域 (Area)：例如oss-cn-hangzhou。指定存储路径：可以自定义一个文件夹路径，如img/，便于管理。集成Typora与PicGo：打开Typora的“偏好设置”，找到“图像”选项。在“上传服务设定”中，选择“PicGo(app)”。指定PicGo应用程序的路径。点击“验证图片上传选项”按钮，如果看到成功提示，则说明整个链路已经打通。 完成以上配置后，整个工作流就变得非常顺畅。当在Typora中粘贴或拖入一张本地图片时，PicGo会自动在后台接管，将其上传到阿里云OSS，然后将返回的URL链接替换掉文档中原始的本地路径。整个过程几乎是瞬时的，对于写作者来说完全无感。 至此，Markdown文档的图片引用问题得到了一个比较完善的解决。它确保了文档的独立性和可移植性，无论是在不同设备间同步，还是分享给他人，都能保证图文并茂的完整呈现。虽然前期需要一些简单的配置，但这种“一次配置，长久省心”的投入，对于维护一个清晰、可靠的个人知识库而言，是值得的。
-
效率的悖论：从“我来更快”到“构建脚手架” 作为技术出身的项目经理，我们常陷入“自己做比教人做更快”的效率陷阱。本文记录了我在项目运维中关于“放”与“收”的挣扎，探讨如何避免成为团队的“单点故障”，并通过构建SOP和验证机制实现真正的技术管理转型。1. 肌肉记忆与效率陷阱作为项目现场负责技术兜底的人，似乎养成了一种肌肉记忆。当一个问题或任务抛过来，大脑几乎是本能地在几秒钟内完成解析、建模，并规划出一条自认为的最优路径。紧接着，一个念头就会自动浮现：“我自己来吧。”这的确常常是风险最低、效率最高的选项。尤其是在临时任务压境、Deadline迫在眉睫的时刻。与其花费半小时去讲解背景、梳理一个可能对方听起来云里雾里的逻辑，再搭上不确定的时间等待一个可能需要打回返工的结果，不如自己花一小时直接搞定。这种“短平快”的决策能迅速扑灭眼前的火，带来一种一切尽在掌控的安全感。2. 隐性成本与无力感但最近这大半年，这种安全感背后的隐性成本，正变得越来越清晰和沉重。有些工作，自认为交代得足够清楚，甚至提供了详尽的步骤和参考案例，可拿回来的结果依然会偏离轨道，有时偏离的角度还颇为清奇。于是，新一轮的时间消耗开始了：定位问题 -> 复盘逻辑 -> 指导修改 -> 重新验证。这一整套流程消耗的时间和心力，常常远超最初的预期。几次三番下来，一种无力感油然而生，潜意识里那个声音会变得更响：“算了，还是自己来吧。”这不仅是一种自我保护，更像是在当前有限的资源下，为了保证项目整体产出而做出的无奈妥协。3. 投资回报与战略空间然而，凡事都有另一面。团队里也有学习能力很强的伙伴。当把一个相对核心的模块交给他时，初期也需要反复沟通平台的历史逻辑和各种“坑”。但关键的区别在于，这些沟通是高效且双向的。当他第一次独立且漂亮地解决一个复杂的 ETL 故障时，那种感受是完全不同的。它不是自己搞定一个难题后的成就感，而更像是一种“投资”获得了超额回报的欣慰。之前花费的所有沟通和培训的时间，都实实在在地转化为了团队战斗力的提升。更重要的是，我终于可以从那块业务中稍微抽身，去思考一些更宏观的规划——比如优化整个数据共享的审批流程，或是用 Vue 搭一个下一个迭代版本的功能原型。这种“放手”成功后带来的，不仅是某个具体任务的完成，而是一种战略空间的拓展。4. 核心危机：单点故障 (SPOF)这两类截然不同的体验反复交织，迫使人不得不去直面那个核心问题：“放”与“收”的边界到底在哪里？把所有事情都自己扛，短期看，项目稳如泰山，交付质量无可挑剔。但长期来看，这种模式存在巨大的隐患：1. 团队天花板：我自己会成为团队能力提升的天花板。2. 单点故障：当所有的疑难杂症最终都汇集到一个人身上，这个点就变得极其脆弱。万一我休假或被紧急事务缠住，团队的响应速度将大打折扣。3. 螺丝钉化：团队成员因为长期接触不到核心任务而失去成长机会，最终变成被动执行的“螺丝钉”。一个健康的团队，绝不能过度依赖某一个“超级英雄”。把事情“收”回来自己做，解决的是当下的、具体的问题；而花心思去思考如何把事情“放”出去，解决的才是未来的、系统性的问题。这背后，其实是个人身份的转变——从一个高级工程师，到一个真正的项目管理者的艰难蜕变。5. 刻意练习：搭建“脚手架”这更像是一种对自己的鞭策和刻意练习。不能因为畏惧返工的风险，就因噎废食。我开始尝试在任务清单面前进行更冷静的划分：* 战略要务：涉及核心稳定、风险极高、必须亲自兜底的任务。* 常规战役：流程相对固定、有犯错空间、适合用来培养团队能力的任务。对于后者，即使预感到过程会艰难，也应该“逼”着自己交出去。但这并非盲目放任，而是需要搭建起必要的“脚手架”： 📄 标准化文档 (SOP)：提供一份详尽到可以按图索骥的操作指南。 🚩 检查点 (Checkpoints)：在关键节点预设检查，避免方向性跑偏。 🔄 交叉验证 (Cross-Validation)：建立强制的互测流程。把可能遇到的坑提前预警，把试错的风险控制在可接受的范围内。前期投入的这些管理成本，以及过程中可能需要支付的返工“学费”，从长远看，都是在为团队的健康和自己的精力“存款”。这个平衡点很难找，也没有一劳永逸的公式，但这大概就是接下来，需要持续修炼的最重要的课题。
-
