时政
财经
科技
虚拟货币
其他
登录
#技术方案
关注
大罗SEO
3周前
推油们,请问下有什么比较稳定的微信群聊ai总结和监控方案吗?找了几个不大靠谱的样子,求推荐🙏
#微信群聊
#AI总结
#AI监控
#求推荐
#技术方案
分享
评论 0
0
ilovelife
3周前
#每日推荐 PDF 生成技术方案对比
#PDF生成
#技术方案
#对比
#每日推荐
分享
评论 0
0
ginobefun
1个月前
一提到「公司政治」,多数工程师的第一反应是远离。但如果有一种方法,既能让你告别内耗,又能让你的技术方案获得高层鼎力支持,你是否愿意了解? 这篇博客的作者认为,工程师最大的错误就是试图去玩一场自己不擅长的「权力的游戏」。相反,真正有效的策略是看懂规则,然后选择在正确的时间,将你早已准备好的技术方案,递到最需要它的高管手中。这篇文章揭示的就是这种「等风来」的智慧,一种更适合技术人的生存法则。 --------- 作为一名专家工程师,我是如何影响公司政治的 作者:sean goedecke 原文: 很多软件工程师对公司政治都抱着一种听天由命的态度。他们觉得掺和进去纯属白费力气,因为: - 技术决策的背后往往是纯粹的私心,一个善意的工程师根本影响不了。 - 那些手握重权的利益相关者,通常既愚蠢又混乱,你根本没法搞懂他们的真实需求,更别提拿出解决方案了。 - 所谓的政治博弈,靠的是工程师压根接触不到的内部消息。你要是贸然参与,只会在里面瞎转悠。 - 管理层和高管们大部分时间都在搞政治,而工程师大部分时间都在搞技术。所以工程师还没下场,就已经输在了起跑线上。 总而言之,大家普遍认为,软件工程师根本就不是玩这套游戏的料。没错! 工程师要是觉得自己也能像《权力的游戏》里那样运筹帷幄、搞阴谋诡计,那可就大错特错了。你的那点小九九很快就会被识破,然后被别人利用,让你吃亏,让他们获利。玩心计需要经验和权力,这两样东西工程师都没有。 事实就是,在大公司里,软件工程师往往是政治博弈中的棋子,而不是棋手。不过,不玩权谋,不代表你不能参与政治。 顺势而为,而非凭空创造 最简单的方法,就是主动投入,把一个高调的项目做成功。这差不多是你本来就该做好的分内工作。如果公司正在大力投资某个新项目 —— 比如现在最火的 AI 项目 —— 你用自己的技术把它做成,对于主导这个项目的副总裁或高管来说,就是送上了一份政治大礼。作为回报,你也能得到高管们能给的好处:奖金、晋升上的帮助,以及未来参与更多明星项目的机会。 一个稍微难点但让你更有主动权的方法,是让你自己的私藏项目搭上高层关注的顺风车。 比如,你早就想把某个现有功能抽出来做成一个独立服务。想实现它,你有两种办法。 难的办法是消耗你自己的政治资本:到处游说,争取支持,告诉你的经理这对你有多重要,慢慢磨到大家都不反对了,项目才可能被正式批准。 简单的办法是,让某个高管用他那多得多的政治资本来推你的项目。你要做的,是等到公司自上而下地推行某个目标,而这个目标正好和你的项目方向一致时(比如,在发生了一次重大线上事故后,公司开始强调可靠性)。这时候,你再跟你的经理提议,说你的项目可能很适合这个大方向。如果你判断对了,你的整个组织都会支持你的项目。而且,这非但不会消耗你的政治资本,反而会增加它。 准备好你的“弹药库” 公司的关注点总是一阵一阵的。强调“可靠性”的时候,VP 们都急于“做点什么”。他们想找一些听起来靠谱的可靠性项目来投资,因为他们需要向自己的老板汇报工作,但他们自己又没能力凭空想出来。所以,工程团队提上来的任何建议,他们通常都很乐意买单。反过来,当公司的注意力在别的地方 —— 比如要发布一个重磅新产品 —— 他们最不希望看到的,就是工程师把时间花在客户完全感知不到的、为了内部可靠性而做的重构上。 所以,如果你想在科技公司里把某件技术性的事情做成,你就得学会等风来。 一个好方法是提前准备好几个不同方向的技术方案。厉害的工程师在日常工作中就会有意识地做这些储备。比如,你可能已经有了一些初步计划: - 把计费代码从缓存 API 调用改成基于 webhook 更新存储数据。 - 用 Vite 替换掉那个老掉牙的手摇构建流程。 - 把一个笨重的、高流量的 Python 服务用 Golang 重写。 - 把那个加载缓慢的、支撑着公开文档的 CMS 前端,换成一个快速的静态网站。 当高管们开始关心计费问题时,你就可以把计费重构方案作为可靠性改进提出来。当他们关心开发者体验时,你可以建议替换构建流程。当客户抱怨性能时,你可以指出用 Golang 重写是个好选择。当 CEO 看了眼公开文档,觉得很丢人时,你就可以提议把它重建成静态网站。最关键的是,无论当下的“月度风向”是什么,你手里都要有一个详细、可行的方案随时准备好。 你的职责所在 不管你做不做这些准备,反正总得有项目被推行。但如果你不这样做,你就没法控制到底是什么项目。依我之见,这恰恰是公司做出最烂技术决策的时刻:当“必须做点什么”的政治需求,撞上了“没啥好点子”的窘境。没有好主意,那烂主意也只能凑合了。 但没人想要这种结果。高管们很难受,因为他们得把一个令人失望的技术成果包装成成功案例去汇报;工程师们也很难受,因为他们得把时间和精力浪费在错误的事情上。 如果你是一个非常资深的工程师,VP 们私下里会把这笔账算在你头上。而且他们这么做是对的!在正确的时间点,准备好正确的方案,这本身就是你的职责。 你可以从两种角度来看待这一切。从悲观的角度看,我这是在建议你把自己变成一个方便的工具,好让那些管理公司的野心家们,在他们无休止的内部权力斗争中利用你。从乐观的角度看,我这是在建议你让高管们去设定公司的总体优先事项 —— 毕竟那是他们的工作 —— 然后你再把自己的技术规划与之对齐。 无论你怎么看,只要能在正确的时间点推动正确的计划,你就能实现更多的技术目标。
#公司政治
#工程师
#技术方案
#高管支持
#生存法则
分享
评论 0
0
一只能天使
3个月前
我还是觉得换电方案更现实一点
#换电
#新能源汽车
#技术方案
#可行性
#积极
分享
评论 0
0
凤凰网-凤凰网综合
5个月前
俄副总理:中国提出需求,俄方愿意保障,需引入具体的技术方案
#俄中合作
#技术方案
#中俄关系
分享
评论 0
0
idoubi
8个月前
AI 生成代码,实时预览的几种方案👇 一、 html + srcdoc + iframe 1. AI 生成可以通过浏览器直接打开的 html 文件(单文件,html/css/js 写到一起) 2. 通过 iframe 的 srcdoc 传入 html 源码预览 3. 通过 importmap 指定依赖包的 CDN 资源。 这种方案实现起来简单,预览效率高。 二、react/vue + blob + iframe 1. AI 生成 react / vue 组件代码(单文件组件,无本地 import 依赖) 2. 通过 Babel.transform 转换 react 组件/通过 VueCompiler 编译 vue 组件 3. 使用转换/编译后的组件,构建一个 html 文件 4. 使用 blob 构建预览 url,传入 iframe.src 预览 const blob = new Blob([html], { type: 'text/html' }); iframe.src = URL.createObjectURL(blob); 这种方案稍微复杂一些,适合 react / vue 单文件组件预览。 3. webcontainer 1. AI 生成组件代码(可以返回多个组件文件,组件可以互相 import) 2. 构建一个最小可运行的 vite 项目骨架,把 vite 骨架包含的文件和 AI 生成的组件打包在一起,构建一个文件树 3. 启动 webcontainer 容器,挂载文件树 4. 通过 webcontainer 执行终端命令,安装项目依赖 5. 通过 webcontainer 启动预览服务,得到预览地址 6. 把预览地址传入 webcontainer 容器外的 iframe.src 实现项目预览 这种方案依赖 webcontainer,可以实现多组件预览,灵活性更高,但是涉及到文件挂载,命令行安装依赖等步骤,预览速度会慢一些。 ----- 总结 ----- 方案一适合用户不关心代码,只想快点看到效果的场景,比如用 Pagen 一句话生成 landing page,页面内容都在一个 html 文件里面。 方案二适合辅助前端写组件场景。比如用 CopyWeb 截图复刻设计,生成单个 react 组件,在线预览效果,导出到本地项目使用。 方案三适合一句话生成完整项目场景,比如用 bolt/v0 一句话生成 nextjs 项目骨架,可在线预览,可导出 zip 到本地修改。
#AI生成
#代码预览
#实时预览
#HTML
#浏览器
#前端开发
#技术方案
#React
#Vue
#框架对比
分享
评论 0
0
个人主页
通知
我的投稿
我的关注
我的拉黑
我的评论
我的点赞