精选项目
按问题 -> 决策 -> 结果来讲的案例。
nnzen 模型目录
一个有 500+ 张模型卡片的在线目录，方便更少依赖人工比较地选模型。
重要数字都放在了一个地方。
不用再手动拼出整张图。
问题: 模型信息散落在不同来源里，价格、上下文、限制和质量信号都得人工核对。
结果: 选模型从翻很多标签页，变成看一页就够。
带 MCP 的定制代理核心
面向开发者助手的 LLM 核心和插件执行层：热重载、工具链和显式上下文传递。
插件可以在不重启整个助手的情况下演进。
这是一个耐用的执行层，不是一锤子演示。
问题: 助手一旦复杂起来，插件就很难继续演进，编排也很容易变脆。
结果: 结果不是一次性的原型，而是一个可以继续加新流程和工具的复用核心。
面向游戏市场的交易自动化
面向一个限制很多的外部市场做自动化：策略逻辑、执行控制和日志都要有。
执行靠服务逻辑，不靠脆弱的 UI 自动化。
重点不是自动化花活，而是可控的执行、日志和策略。
问题: 这个平台足够不稳定，朴素脚本很快就会失效。
结果: 系统能在平台变化下继续工作，而不是一下子散掉。
稳定的数据采集
针对不断变化的网页环境做数据采集工具，长期面对反爬摩擦。
稳定性来自对请求流的理解。
稳定性是靠网络和 JavaScript 分析提上来的，不是靠无穷重试。
问题: 常规采集方法总是因为页面漂移、客户端逻辑和防护机制而失效。
结果: 少了救火，多了可预期的提取过程。
我的主 профиль
我在找的，是那种需要服务架构、集成和稳定生产交付的 Python 后端岗位。
核心方向：Python 后端，外加很强的集成和运维意识。
- 我能稳定处理 Linux 服务器、Docker 化交付，以及 Caddy / Nginx 风格的部署路径。
- 基础设施上我偏务实：以自托管交付为主，边界清楚。
经历
我更喜欢用问题 -> 决策 -> 结果来讲经历：哪里有风险、我做了什么决定、发布后发生了什么变化。
后端 / 集成工程师
自由职业
合同 · 独立负责到交付
围绕真实业务流程交付后端、集成和自动化系统：外部 API、流程自动化、AI 辅助功能，以及生产环境里的质量控制。
- 把模糊需求拆成可维护的服务，并明确 API 契约和支持边界。
- 为不稳定的外部系统设计集成，补上错误处理、重试、日志和可观测性。
- 通过可复用模块和集成模式，缩短新流程的交付时间。
独立 R&D 工程师
独立项目 / 研究
自主研究
在合同之间做后端和 AI 研究，用原型先验证架构，再把能用的部分带回到生产相关工作里。
- 在客户使用前，先用可运行的原型验证了 RAG 和工具调用模式。
- 从一次性脚本转向可复用、接口清晰的服务组件。
- 为后续的应用型 AI 和 AI 工具项目打下了实践基础。
R&D 数据采集工程师
Bright Data
全职
在不断变化的网页环境里做数据采集工具：HTTP / JavaScript 分析、稳健的请求流，以及快速适应变化。
- 分析不稳定的请求链路，并把它们整理成更稳健的提取逻辑。
- 随着反爬策略和页面结构变化，保持提取质量。
- 在逆向分析、稳定性和交付速度之间工作。
Python 开发者
自由职业
合同合作
为内部流程做 Python 工具、解析器和自动化，面对的是脏数据和经常变化的需求。
- 自动化重复操作，减少数据密集流程里的手工工作。
- 为不稳定的集成写服务工具和解析器。
- 快速把 Python 工具做到能继续维护的状态。
方法
我最擅长的是那些环境有点乱的项目：不稳定的外部 API、别扭的流程，以及叠在真实业务上的 AI 层。我的目标是让交付更可预测，也更容易维护。
- 带清晰 API 契约的 Python 后端
- 面向不稳定外部系统的集成和自动化
- 真正融入流程的应用型 AI 功能（LLM API、RAG、工具调用）
- 上线后的可观测性、调试和支持
我先看外部系统、数据形态、运行风险和维护成本。
我喜欢那种一眼就能看懂数据流和故障边界的系统。
一个方案只有在能监控、能调试、也能安全扩展时才算准备好了。
好的后端会减少手工步骤，也会让下一次发布更便宜。
有个复杂需求？我们把它变成能用的系统。
最适合我的，是那些需求还不够清晰、系统已经在运行、而结果必须经得住生产环境考验的项目。
远程或混合办公；欢迎全职岗位和少量合同合作。