Joe的博客

大模型写稿很爽，但排版让人崩溃，你有没有过这样的体验？ 现在的大模型（如 ChatGPT, Claude, DeepSeek）长文本生成能力已经极其强悍。只要给足提示词，就能瞬间吐出几千字长文。但在实际的办公场景中，我发现用它们来写东西，最后的体验经常是“翻车”的。 为什么？因为在绝大多数的职场和商业环境中，我们并不是在搞纯粹的“自由创作”，而是在撰写高度标准化的文档。体制内公文、法律合同、企业招投标报告、高校科研申请书……这些文档有着近乎苛刻的格式要求。 常规的AI往往无法严格遵循已有的格式要求，而是会脱离你提供的格式要求自由发挥。为了把 AI 写的文本塞进标准模板里，我们不得不小心翼翼地“只保留文本”粘贴，然后再一行一行地重新刷格式。一顿操作下来，调格式、对齐段落的时间，甚至比自己手写还要长。 不仅如此，当前的 AI 交互模式也存在巨大的摩擦力。对于大部分人来说，缺乏一个好用的能够快速上手的app让他们写文档，每次让 AI 写一份新的商业报告或合同，都要不胜其烦地把公司简介、过往项目经历、法务要求等等信息，作为“背景提示词”重新发送一遍，耗费大量的 Token 上下文，更致命的是，

试想这样一个场景：我拥有多台服务器，但这些服务器均没有公网 IP 地址。为此，我租用了一些具备公网 IP 的服务器作为跳板，通过运行 Frp 将内网服务器代理至公网，从而构建起一个由多个节点组成的 FRP 网络。 然而，现有的 FRP 网络在实际运维中有一个明显痛点：每当我需要在这个网络中增加或删除设备，或是调整端口映射时，都必须登录对应的 frpc 节点，手动修改配置文件并重启 frpc 进程。这一过程不仅繁琐，而且在节点数量增多时显得效率低下。 鉴于内网服务器通常具备较高的性能，我们可以借鉴即时通讯系统的设计思想，构建一套统一的管理体系，通过一个监控进程来集中管理整个 FRP 网络，从而避免因网络结构变动而频繁在多台服务器间进行配置操作。 我将该项目命名为 UFM（Union of FRP Manager）。系统整体分为服务端与客户端两部分： 服务端（UFMS）：提供 Web 管理界面，用于管理跳板机与内网服务器之间的端口映射关系。用户可通过该界面添加正在运行的 frps 或 UFMC 节点，动态调整 FRP 网络中的端口设置，并向客户端下达管理指令。 客户端（UFMC）：运行于内

我顺利完成我的博客的所有功能了！！！ 以后会不定时地在这里分享一些有意思的想法，主要关于软件开发以及折腾各种AI软件的，不定时更新 自己从头开始搓一个博客感觉还是很有意思的，如今功能也是越来越丰富了。 大家还可以来我的博客里评论，或者到留言墙留下自己的留言，自定义添加友情链接。